moq-wg / moq-transport

draft-ietf-moq-transport
Other
82 stars 20 forks source link

Should any priority values indicate "Less than best effort"? / How do you upswitch without causing user harm? #471

Open ianswett opened 3 months ago

ianswett commented 3 months ago

There was a discussion at the interim about how having one or more priority values indicate less than best effort might be useful, and I believe client side ABR is a good use case.

How does a client decide to switch to a higher quality? With the proposed priority scheme, the higher quality could be made lower priority, but it doesn't prevent higher quality data from consuming a large portion of the bandwidth and causing congestion that negatively impacts delivery of the lower quality.

To give a typical example, the client is considering switching to the next highest quality, which is 2x the high bitrate of the current video quality. The current quality is consuming slightly more than 1/2 of the subscriber's bandwidth, so the subscriber will not have the bandwidth to switch to the higher quality. Without caution, too much data could be sent and cause bufferbloat and/or loss.

My strawman proposal is that LBE means is that if the publisher only had LBE content to send, it would alter its behavior in terms of how much/when to send. For example, the core BBR model sets the CWND to 2BDP the vast majority of the time, but maybe LBE would not be sent unless CWND is < 1.5BDP. This ensures there is always CWND available for higher priority data. Ideally BBR should be pacing limited, and when it's CWND limited, something is typically going poorly.

fluffy commented 2 months ago

FWIW ... I took the discussion about less than best effort to mean that we the DSCP markings for the data would be LE as defined in https://www.rfc-editor.org/rfc/rfc8622.html - I can see value in BBR being aware if data was less than best effort or not.

alvestrand commented 2 months ago

Does QUIC have options to vary DSCP between different packets on the same connection? I remember that when we discussed DSCP in WebRTC, we landed on a recommendation that all packets under a single congestion controller MUST use the same DSCP codepoint.

I've been believing that MOQ priority was "local priority" as defined by https://github.com/w3c/webrtc-priority/issues/7