Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
RTCPriorityType combines relative bitrate with QoS priority, which applications may not want. #1625
This may really be an issue with https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/, but also may be a result of me interpreting it in a way other than intended, so I thought I'd raise the issue here first.
Anyway, rtcweb-transports says:
The sections below are "Local prioritization" and "Usage of Quality of Service - DSCP and Multiplexing". The "local prioritization" section gives this guidance:
This has two significant issues I can see:
So, why do we have one enum for both things? I'd propose defining RTCPriorityType as something that only impacts the priority in network queues (QoS-level priority and SCTP priority, as previously discussed), and use something else to control the relative bitrate allocation.
For example, a floating point value attached to each
In general, I agree that the priority model is conflating too many things.
In trying to implement the priority model, there were a number of obstacles:
In practice, Windows only permits setting the DSCP code point on a per-socket, not per-packet basis.
Also, SCTP implementations typically do not have pluggable congestion control or a way to share bandwidth estimates with RTP, so loss-based data channel can compete with delay-based A/V congestion control. QUIC looks like a promising way to address this issue (particularly if QUIC could be configured to utilize delay-based congestion control).
Can't you use QOSSetFlow? From MSDN:
Or are there practical limits to this?
I thought POSIX OSes do, by calling
But anyway: even ignoring the issues related to QoS and multiple congestion controllers, it sounds like we agree that the "1:2" ratios are too limiting, and that mixing this up with QoS is undesirable.
I think the problems and limitations both of you describe have been known since way back, but we (the rtcweb+webrtc community) accepted them (at the time) as good enough for v1.
Fixes w3c#1625. This provides more fine-grained control over the relative amount of bits different encodings should be allocated. This allows the webrtc implementation to respond quickly to changes in available capacity; the alternative would be for an application to inspect the stats periodically, and continually adjust `maxBitrate`, which would result in wasted bandwidth and slower responsiveness to changing bandwidth estimates (since polling stats and calling getParameters/setParameters is not instantaneous). This assumes that rtcweb-transports will update its definition of "priority," such that it only controls the priority of streams in network queues (via DSCP and SCTP priority values), and not the relative amount of bitrate they're granted.