Re: Receiver Estimated Bitrate Extension

[Martin Thomson <[e-mail]>]

Hi Luke,

An interesting idea.  The conceptual overlap with SCONE and Martin Duke's SCONE signal (https://datatracker.ietf.org/doc/html/draft-duke-scone-scone-echo) 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).