search

quic-go / quic-go

A QUIC implementation in pure Go
https://quic-go.net
MIT License
10.16k stars 1.32k forks source link

Exposing bandwidth estimate #4726

Open any1 opened 1 week ago

any1 commented 1 week ago

I would like to expose the bandwidth estimate via the API, and I was wondering if such a change would be accepted.

When encoding video for streaming, it is often possible to set a bandwidth limit. This reduces the quality of the video instead of dropping frames which often a better alternative, depending on the application and the degree to which quality would need to be reduced.

It would be nice (and probably also more accurate) to be able to get the bandwidth estimate from the quic API instead of having to calculate it based on own RTT measurements and sizes of outgoing frames.

marten-seemann commented 1 week ago

Sounds reasonable, but we need to be very careful to expose something that's actually useful.

The bandwidth estimate is very dependent on the congestion controller in use. For example, with loss-based congestion controllers like Reno or Cubic (as we're implementing right now), the estimate will vary greatly around the time of packet loss (since a packet loss causes a reduction of the cwnd by 30%). When using a non-queue-building congestion controller like BBR or Prague (which we currently don't implement, but might at some point in the future), the bandwidth estimate will likely not fluctuate that sharply.

Do you have any concrete suggestions?

We should probably also expose an RTT estimate (latest, smoothed?).

any1 commented 1 week ago

Do you have any concrete suggestions?

Not really. I would have to do some actual experiments with quic. I can tell you that, in my experience, estimating bandwidth over TCP by reporting bytes received from the receiver in combination with RTT of such reports and min RTT tends to underestimate the available bandwidth. I suspect that this may be a result of underutilising the congestion window. To be honest I've just started dipping my toes into the water in this part of the pool.

We should probably also expose an RTT estimate (latest, smoothed?).

I suppose that it might be useful to have a somewhat direct estimate of the expected latency of the stream, even if only for debugging and metrics.