Hi
I think I then understand. The purpose is to leave the congestion controller to work as before but deliberately retransmit STREAM frames to make it possible to seek capacity. As per the example below: The PROBE_REQUEST is to make it possible for a client to indicate that it would prefer to receive up to 1080p, the server can then try and probe up to 6Mbps (with a lower media rate) and switch over to 1080p when that thorughput is reached. Possibly one need to probe a bit higher than 6Mbps to avoid frequent jumps between 1080p and 720p as the actual rate can vary around the nominal ditto. So, unless I still misunderstand, I think this can be useful and does not seem to need anything extra from congestion controllers. Seen from a cellular perspective, it is useful too as the probing makes it possible to add extra carriers if needed. Addition of carriers is something that is best done on a per need basis to optimize battery usage in devices. /Ingemar From: Luke Curley <[email protected]> Sent: Friday, 12 June 2026 21:05 To: Ingemar Johansson S <[email protected]> Cc: IETF QUIC WG <[email protected]>; Martin Thomson <[email protected]>; Roberto Peon <[email protected]> Subject: Re: Receiver Estimated Bitrate Extension Okay a few replies. I'm bad at inline replies, so I'm quoting random emails instead. I have been working with SCReAM v2 (standardized in CCWG), SCReAM is generally blessed with real time video that can be monotically increased and thus it does not get stuck at low rates, unless the video encoder does something strange. The bitrate will increase up to the max video bitrate and then it will become application limited. Yeah the difference is that we're targeting the HLS/DASH use-case: mass distribution. If you have thousands of viewers, none of their feedback can meaningfully impact the encoder. We instead encode multiple renditions at different bitrates: * 1080p @ 6Mb/s * 720p @ 3Mb/s * 480p @ 1.5Mb/s * 360 @ 0.75Mb/s * etc If a user is watching at 480p, we can't increase the encoded bitrate just for them, because hundreds of other viewers are also watching at 480p. We can only probe for higher bitrates at the network layer. In the current implementation of SCReAM in WebRTC, padding is used to fill up the reference window when the video encoder does not deliver enough to make bytes in flight match the reference window enough. This makes it possible for SCReAM to probe capacity nicely. Yeah, that's basically what I'm proposing, but improved. libwebrtc opts to retransmit in-flight packets first and only falls back to padding if nothing else is available. I think RTX is required so TWCC benefits from the retransmitted packets, but I don't remember. Actually I asked Claude to find the code if you're curious: https://chromium.googlesource.com/external/webrtc/+/HEAD/modules/rtp_rtcp/source/rtp_sender.cc#385 The equivalent in QUIC is to retransmit existing STREAM frames and only resort to PING/PADDING if nothing is in flight. We don't need an RTX/TWCC extension because it's built into QUIC. (The idea is that you ramp up your FEC rate to generate more bandwidth demand, and the increased FEC protects you from the losses that may cause when the path can’t deliver that bandwidth.) Yep, exact same idea. Enabling FEC would be better than duplicate transmissions (RED in WebRTC) but I'm sending redundant STREAM frames because QUIC supports it natively. I'm not following your proposal from here. Can you explain a little more about what is going on here? Who is sending each message (I'm guessing the client is on the left)? Is there some timing assumed that I'm missing? What goals are each of these messages help drive? Or, put differently: who is driving the rate increase? And how does awareness of the sender bitrate help? Each viewer (HTTP client for HLS/DASH) sends a PROBE_REQUEST. If there's a higher rendition they want to switch to, they include the target bitrate in the request. The target bitrate for each rendition is determined by the application, for example a playlist/catalog. Each viewer might want some overhead (ex. target 7.5Mb/s instead of 6Mb/s for 1080p) or they might not want to switch up at all (ex. screen size is small, 480p is good enough). The sender (HTTP server for HLS/DASH) periodically sends a PROBE_STATUS (I just bikeshedded the name lul). It queries the estimated bitrate from its congestion controller and transmits that information to the peer. And note that none of this proposal is viewer specific. For example, you could have an ingest server send a PROBE_REQUEST to a broadcaster before it subscribes to a high bitrate track. It's a way for the receiver to tell a sender to warm up the congestion controller. On Fri, Jun 12, 2026 at 2:36 AM Ingemar Johansson S <[email protected] <mailto:[email protected]> > wrote: Hi I try to understand the scenario. I have been working with SCReAM v2 (standardized in CCWG), SCReAM is generally blessed with real time video that can be monotically increased and thus it does not get stuck at low rates, unless the video encoder does something strange. The bitrate will increase up to the max video bitrate and then it will become application limited. In the current implementation of SCReAM in WebRTC, padding is used to fill up the reference window when the video encoder does not deliver enough to make bytes in flight match the reference window enough. This makes it possible for SCReAM to probe capacity nicely. Perhaps something like this can be used also in your case below. The drawback is that you can end up with a lot of padding, for instance if the media rate is 3Mbps and the link thorughput is 5Mbps. But perhaps periodic padding can work even though it makes capacity probing slower. And maybe it’s something like this that you propose ? But I don’t understandt why you need to have extra signaling for this ? /Ingemar From: Luke Curley < <mailto:[email protected]> [email protected]> Sent: Friday, 12 June 2026 00:49 To: IETF QUIC WG < <mailto:[email protected]> [email protected]> Subject: Receiver Estimated Bitrate Extension Hey Quicers, I presented an extension <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-lcurley-moq-probe-00.html&data=05%7C02%7Cingemar.s.johansson%40ericsson.com%7C011a0cc006784e45d2f108dec8b58ac3%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639168879230798538%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uH3ETEWG3LznoiuO3hEmhdHTInka67HS%2BDBUBw4miiQ%3D&reserved=0> to the MoQ working group and Ian suggested it could/should be in QUIC instead. tl;dr A way for receivers to know the sender's estimated bitrate and to request increasing it. The problem involves application-limited flows like live media. Suppose we're currently downloading a 3Mb/s video stream (720p) and need to decide if our connection can support 6Mb/s (1080p). There's no way to gradually increase the media bitrate; these renditions are fixed. The viewer buffers (spinny boye) if we try to download an unsustainable rendition. Unfortunately, individual media frames may not be large enough to fill the congestion window. CUBIC/Reno/BBR can't increase the window/pacing rate unless the connection is fully utilized (not application-limited). We get stuck with an artificially low bitrate estimate that won't reach 6Mb/s unless bufferbloat causes some queuing (ironic). I-frames cause a tiny burst but it's never enough. HLS/LL-HLS avoids this problem by batching frames, allowing us to burst these fragments (usually at least 500ms) to saturate the window. However, this increases latency by the same amount. Twitch wanted to avoid adding any latency and instead "solved" this issue by running a periodic speed test, downloading 128KB of zeroes. But WebRTC has a better solution. It periodically probes higher bitrates by speculatively retransmitting media in flight. The QUIC equivalent would be retransmitting STREAM frames that have not yet been marked as lost. This adds a crude form of redundancy, so even if our probe causes packet loss, it partially masks the problem. I implemented this for our MoQ rollout (10%) while at Twitch. The average production bitrate increased roughly 1Mb/s (3 -> 4) compared to the existing client-side ABR, all because we were more confidently able to switch to higher renditions. But they ended up laying off 80% of the company and shuttering the baremetal CDN, so take my anecdote with a grain of salt lul. My MoQ extension more-or-less looks like this: --> PROBE_REQUEST target_bitrate=0 <-- PROBE_RESPONSE estimated_bitrate=3000000 <-- PROBE_RESPONSE estimated_bitrate=3123456 --> PROBE_REQUEST target_bitrate=6000000 <-- PROBE_RESPONSE estimated_bitrate=4999999 <-- PROBE_RESPONSE estimated_bitrate=6233345 (success, we can switch up) Now the important question: Would this be the sort of extension that would be useful at the QUIC layer? We don't need a QUIC extension because a sender can already implement this. All QUIC receivers MUST be prepared to receive overlapping STREAM frames, as that can happen naturally due to ack timers. If application limited, the QUIC library just needs to retransmit some STREAM frames already in flight. At a minimum, I need an API to get the sender's estimated bitrate (very common) and another to probe for a higher bitrate (afaik no implementations exist). This is the type of thing we'll need in the WebTransport API (W3C) if we ever want to reach WebRTC parity. But it's not clear if we should transmit these PROBE_XXX messages at the QUIC layer or as part of MoQ. It could be useful for other application-limited protocols, and tighter integration with the QUIC stack could help (ex. send a PROBE_RESPONSE immediately after processing an ACK).
smime.p7s
Description: S/MIME cryptographic signature
