Subject: Re: [rtcweb] Issue with "priority" defined in rtcweb-transports

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 2 Nov 2017 09:10:48 +0000

Taylor,

do you have any data associated to this that can be shared?

It's very easy to get into a discussion where people want knobs for a 
lot of things (like min bitrate, desired bitrate, max bitrate, relative 
priority, sender queue knob, set DSCP knob, ...), but it would be good 
to have some observations/real data to base decisions on.

--Stefan

On 11/10/17 19:30, Taylor Brandstetter wrote:
> (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.
>