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 <[email protected]> Sent: Friday, 12 June 2026 00:49 To: IETF QUIC WG <[email protected]> Subject: Receiver Estimated Bitrate Extension Hey Quicers, I presented an extension <https://www.ietf.org/archive/id/draft-lcurley-moq-probe-00.html> 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
