[webrtc-pc] RTCPriorityType combines relative bitrate with QoS priority, which applications may not want.

taylor-b has just created a new issue for https://github.com/w3c/webrtc-pc:

== RTCPriorityType combines relative bitrate with QoS priority, which applications may not want. ==
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 WebRTC prioritization model is that the application tells the
>    WebRTC endpoint about the priority of media and data that is
>    controlled from the API.
>    ...
>    The priority settings affect two pieces of behavior: Packet send
>    sequence decisions and packet markings.  Each is described in its own
>    section below.

The sections below are "Local prioritization" and "Usage of Quality of Service - DSCP and Multiplexing". The "local prioritization" section gives this guidance:

>    When an WebRTC endpoint has packets to send on multiple streams that
>    are congestion-controlled under the same congestion control regime,
>    the WebRTC endpoint SHOULD cause data to be emitted in such a way
>    that **each stream at each level of priority is being given
>    approximately twice the transmission capacity (measured in payload
>    bytes) of the level below.**
>
>    Thus, when congestion occurs, a "high" priority flow will have the
>    ability to send 8 times as much data as a "very-low" priority flow if
>    both have data to send.  This prioritization is independent of the
>    media type.  The details of which packet to send first are
>    implementation defined.
> 
>    For example: If there is a high priority audio flow sending 100 byte
>    packets, and a low priority video flow sending 1000 byte packets, and
>    outgoing capacity exists for sending >5000 payload bytes, it would be
>    appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes
>    (one packet) of video as the result of a single pass of sending
>    decisions.

This has two significant issues I can see:

* It only allows ratios of 1:2:4:8. This is not granular enough to be very useful.
* A single enum is used for both relative bitrate, and relative QoS priority. But in my experience it's common for an application to want a flow that uses _less_ bitrate to have a _higher_ QoS priority. This may even be the _more_ common situation.

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 `RTCEncodingParameters` (say, `relativeCapacity`), where an encoding with twice the `relativeCapacity` of another encoding will be given twice the transmission capacity. If implementations can handle ratios of 1:2:4:8, I don't see any reason why they shouldn't be able to handle arbitrary ratios.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1625 using your GitHub account

Received on Tuesday, 10 October 2017 22:51:24 UTC