From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by mail.toke.dk (Postfix) with ESMTPS id D5811A93D5E for ; Mon, 28 Oct 2024 20:23:10 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=lwefLJtk Received: by mail-oi1-x231.google.com with SMTP id 5614622812f47-3e5f533e1c2so2603489b6e.3 for ; Mon, 28 Oct 2024 12:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730143389; x=1730748189; darn=lists.galene.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JaJxMTGOC2vg3mRYUQOYiY8VyH+63oKLtQOmQYdpUIA=; b=lwefLJtk8Jw1sbzSW4K2U1qkVxZ9WGN425zGVL3aN+AeH9JFYJNeCs1xO6zvCT5HSi yWVkHJDN4Rq/7mvx4OQWGGlGfj3wupFL/CrSobDv9FXzgWSiJrT7b5v1KPB/2hzoVEk/ 1uD7/gOk6GXbCBy/93MfoBlkgsYDu1CIcyUsfFGBYfzuU/Sh+dHdKxAaF9/ytrpub2+E 0PqnD1gz2JafLdZC5gk7DEyRH1yG2eC0PtxRm8TisfUE4cSRTLQoFZ+9v2kV7m2uqrVQ xS27fC4vr3D7780/twB8TyfqSbdXZOZ266S4qL7mHmOEqLOD7n2PyBoUmAORugrgaAby 9xwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730143389; x=1730748189; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JaJxMTGOC2vg3mRYUQOYiY8VyH+63oKLtQOmQYdpUIA=; b=ZdQoS0EMGvqDeZnrNcPl3lKtlT/S0jwpPLxfFRfdd7qFEKB+l14kCU96gT6mSejjg4 UHBc7fph70PuyVVZSrZKQBYGsOVNOAqhCOFjHdIoazez6h484gOprAZxBQYFQ/63yU7C rm4Qudng7967OJOp9E6pko/cX+pae9Hd7eETl2V5onXDMMF0gzJspi/+twK0mDdLv3C0 kn1KEbkEonzggEbSMsW5qLvQ0uTrTl5OjUWjMCrwS1yyexzL9lXOyC9zU+PgMUed175a I92rj1ktcbzI+KkuZ7QZVHNzKNP2TCxnIJ43CLlTQu8wwtsIWOWmiHnb54M9opqXH/mh pBeg== X-Forwarded-Encrypted: i=1; AJvYcCWssF4XuxE/Fdr1X1T3SQ0llpmTg3Sl3oSn66U0emJNxqnFM1pZE/lU//8ncQ6ROWeRC6/wBzY=@lists.galene.org X-Gm-Message-State: AOJu0YzqBrhhLdmIJr5WlmVMM6XzAQlzwSlr9kKv43TtUT7uO0z1h5DM C97zZMtPBg1oex54ezQKikBogJhQpOfdvRs/6Ouwhab2DlAMMJ1/YOpkbAWER/k1hUmYEgCWU5E yMPD7TDqx9Y2GS/KY8S9bonFuO3I= X-Google-Smtp-Source: AGHT+IGf6GHCv1GYUoF5oLsPdq8Xb1fqIltFwR5mQSd2IQSgKDw+xwhtlCTTgoJdbw+HUlj3AtI3izDC8iL+Z32psBw= X-Received: by 2002:a05:6870:3283:b0:27c:475c:ab2c with SMTP id 586e51a60fabf-29051db640bmr8128712fac.43.1730143389330; Mon, 28 Oct 2024 12:23:09 -0700 (PDT) MIME-Version: 1.0 References: <935CC801-1E96-414A-80F0-29DD18617AE1@apple.com> In-Reply-To: <935CC801-1E96-414A-80F0-29DD18617AE1@apple.com> From: Dave Taht Date: Mon, 28 Oct 2024 12:22:56 -0700 Message-ID: To: bloat , galene@lists.galene.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: MHMV3OM4AD4BIV7NY24EBQB6D36VGH27 X-Message-ID-Hash: MHMV3OM4AD4BIV7NY24EBQB6D36VGH27 X-MailFrom: dave.taht@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Galene] Fwd: Seeking input from engineers with expertise in video conferencing and similar delay-sensitive applications List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: If anyone with a videoconferencing background can comment on these methods (to the ippm list, not here) ---------- Forwarded message --------- From: Stuart Cheshire Date: Mon, Oct 28, 2024 at 12:21=E2=80=AFPM Subject: Seeking input from engineers with expertise in video conferencing and similar delay-sensitive applications To: Hello IETF colleagues, The IETF has been working on L4S, to reduce packet loss and delay on the Internet, which should be a great benefit for delay-sensitive applications like video conferencing. In a companion project, we are working on a network measurement tool to report meaningful delay measurements, to validate whether L4S deployments and other similar technologies are actually delivering what they promise. We are seeking expert feedback on this Internet Draft: It will be discussed next Monday at the IETF meeting in Dublin: The purpose of this work is to create a repeatable analytical test that can be run to assess how well a network will support delay-sensitive applications like video conferencing. For the test to be useful, the results it reports need to correlate with subjective user experience. I worry that we have not validated this aspect of the test enough. My understanding is that video conferencing applications accumulate received packets in a playback buffer (to smooth out delay variation), and then determine a time when those packets are decoded to display a frame. Setting the playback buffer too deep results in conversational delay that impacts user experience. Setting the playback buffer too shallow results in lower delay, but risks displaying a frame before all the necessary packets have been received, degrading image (and audio) quality. Thus the playback buffer needs to dynamically adjust to network conditions, to balance between playing early enough to keep conversational delay low, but late enough that a sufficient percentage of packets have been received by the playback time. How does a video conferencing application compute this ideal playback delay? Is the delay set such that we expect 90% of the necessary packets should have been received? 95%? 99%? The draft has been through a series of revisions with input from multiple people. It has currently arrived at an algorithm that samples the application-layer round-trip delay over a period of about ten seconds, discards the worst 5% of those measurements, and reports the arithmetic mean of the the best 95%. Is this a good predictor of video conferencing performance? I fear that our current test may be measuring the exact opposite of what video conferencing cares about. Mean and median mean nothing to video conferencing. If the median round-trip delay is just 1ms then that=E2=80=99= s awesome, but it does a video conferencing application no good to decode a frame when it=E2=80=99s got only half the packets (that=E2=80=99s = what median means). If the 90th percentile round-trip delay is 500ms, and the application needs to have 90% of the packets before it can usefully decode a frame, then the application needs to wait that long before decoding a frame. It doesn=E2=80=99t matter if half the packets arrive real= ly early, if the remaining necessary packets arrive late. It is the latecomers that determine the playback delay, not the early packets. Does my reasoning make sense here? What metric would video conferencing applications like to see reported? 90th percentile? 95th percentile? 99th percentile? Something else? I want to make sure that when we publish this Internet Draft as an IETF RFC it serves its purpose of motivating vendors and operators to tune their networks so that delay-sensitive applications work well. If the test measures the wrong thing, then it motivates vendors and operators to optimize the wrong thing, and that doesn=E2=80=99t help delay-sensitive applications like video conferencing work better. Please send comments to ippm@ietf.org , or attend IPPM in Dublin to share your thoughts in person. Stuart Cheshire --=20 Dave T=C3=A4ht CSO, LibreQos