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]> 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 <[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). > > > > > > >
