This seems like a variant of FEC? I concur that one of the larger reasons for either more latency, or lower quality video delivery is the inability to better probe path goodput. Practically this is true for any 'realtime' application that suffers when latency increases, I believe.
-=R On Thu, Jun 11, 2026 at 4:57 PM Martin Thomson <[email protected]> wrote: > > > Hi Luke, > > An interesting idea. The conceptual overlap with SCONE and Martin Duke's > SCONE signal ( > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-duke-scone-scone-echo__;!!Bt8RZUm9aw!-Cqomsxc82odkGE8Kqw1oFsif-oVyw-ztCzm0vCusEIl31W9GM_5y69ZcFgrzgbwEaa7Xt2D$ > ) is worth considering, though this is clearly stepping beyond that. > > On Fri, Jun 12, 2026, at 08:48, Luke Curley wrote: > > 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. > > Just a note on this. Even if you manage to send every byte twice, which > is unlikely, it can be the case that loss will cause some packets to be > lost. Sending duplicates improves the odds that a loss is covered by the > redundancy, but if you induce loss, you don't necessarily get to chose what > gets hit. > > > 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) > > 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? > > I think that what you are saying is that in cases where the receiver is > choosing the bitrate (or rendition), it helps to have a way for them to ask > the sender to bump their send rate above the bitrate that is active, to > test whether a higher bitrate could be sustained. Is that right? > > If I'm right, then my initial inclination is to suggest that this sort of > thing is so highly application-specific that it doesn't belong in QUIC. I > can definitely see why the machinery for sending at a higher bitrate is a > useful feature to have in QUIC implementations, but that doesn't > necessarily need a QUIC standard to drive it, just an API. MoQ is a > different beast though and a way for the client to request this sort of > thing in MoQ makes more sense to me. > > All that said, if Ian thinks this might be better in QUIC, I'm very > interested in his reasoning. Martin Duke's SCONE signaling thing does > point at there being deployment scenarios where it could be better for > signaling capabilities like this being more generic (I'm not entirely > convinced there, but I can see the case). > >
