[rtcweb] Issue with "priority" defined in rtcweb-transports

[Taylor Brandstetter <[e-mail]>]

(Mainly copied from https://github.com/w3c/webrtc-pc/issues/1625)

When defining priority, 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. Especially when balancing transmission capacity between audio
   tracks and video tracks; in practice it's common for video tracks to use
   much more than 8 times the bitrate of audio tracks.
   - 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 the
priority 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.