From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2c.google.com (mail-oa1-x2c.google.com [IPv6:2001:4860:4864:20::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CEC033B29E for ; Mon, 28 Oct 2024 15:23:10 -0400 (EDT) Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-290d8d53893so650122fac.2 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.bufferbloat.net; 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=cm0m5ueobKA6Ri6Fb0i6WXLf4Rfm/ly3cF5OekwQ6lvvMs7yFRk4YcN/NGmIMvvOfa 9g3FyiiVhBI123Aclo5C1L7+CV3JPqCORQIUqaN+6eCMGBBY403jT3IPGf8wo9GNVg+V ygKVkqa0mVNmO/fmekWWiJ8PC1kHYKbo0N//IIIYhz4gWqAsvjOAcbkf4KpQwJW5RQYn W/+FuPyc8Kzvo1N/WUfEXhuamaRWXBy/Dh+uVP/HVoVpEHIy0VCYaT9+w0E9olZJNiFz 5Y0GfyJEDA0QpQGg0zlDX2JMDNEF9miUv6UxQB0Spcdyv49zEiBSGyGzZDkRpu5OvSHJ YILw== 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=Gm6WE0r6CkTK2yUbDpwiVGMP0NGWT8KeqtlhltIpGT1Zb+gZnBT649lkFbO8Wi/zeP ALnvMiiYA//PINjWKfT1freUK0iCyIC2svwru56YEXYI1loLlHAeoBxnqAHWiKTpd2fH 3oSd187rbRx5m6pNeW++OQtHA1NRFALVZITzLp8is+gn2eSFjXs3PU1pw6RiFQg9NxMy TOW/WQIgjKHA12PYwGJfjNMaDTYf3JJL0JI8pKRCJlXDxGi/LzJ2O3o/fmgoG/lYHJA+ tvr6YUCtImcWb2QUWVnCAtU2EIPIpHe8yAsTNye4GBcuAK7fePaACbwAX1Zh08q/LdcF SObg== X-Gm-Message-State: AOJu0YzESEsMqK8AiLE9DwNmGCUu38K4wXpXRFiJAtQyHtOA0/g7uGWx 4l7gi6uyprZzKoJqsJYUHY46UWpqyIarKN6LhChr0ue3Foz6ar5QameBZjQ78K3R1DqfQGgZe2m aWbJJuIHa/+kUEWCOsNLyGUzwWcsAng== 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 Subject: [Bloat] Fwd: Seeking input from engineers with expertise in video conferencing and similar delay-sensitive applications X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2024 19:23:10 -0000 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