Padding is worse than data redundancy (either FECs or rexmits (arguably degenerate "FEC")) because, while it allows probing bandwidth, it increases the probability of a missed bit of data that causes jitter.
Increased data redundancy arguably lowers the amount of theoretical jitter in most operating regimes. -=R On Fri, Jun 12, 2026 at 2:40 AM Ingemar Johansson S <ingemar.s.johansson= [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). > > > > > > >
