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

[Magnus Westerlund <[e-mail]>]

Hi Taylor,

I think the text you quoted is directly related to your transmission 
queuing. And as no one was willing to write up a specific queuing 
algorithm that would be more flexible, the discussion in the WG at the 
time this was written ended up in a per prioritization level round robin 
queue basically, where each lower priority is given one transmission 
slot in the upper queue. Thus giving roughly halving, but it could be 
less actually depending on how many processes are part of a particular 
level.

I also think you scheme for relative capacity is likely good, but appear 
to be missing two important parameters. One for minimal bit-rate, and 
one for maximum. At least for audio sources, there is a limit to scaling 
these both upwards and downwards. The upper limit when reached should be 
redistributed, or otherwise it might be wasted. The minimal is an 
interesting one. Because one have to decided if this means taking more 
from the lower prioritise and how they relate to other. The classical 
example of one audio plus one video comes to mind, where one would like 
to maintain the audio in user interactive applications despite taking 
more from the video. To the point where one have to turn off video to 
maintain audio.

So, I think you have to work on the proposal a bit more.

Cheers

Magnus


Den 2017-10-11 kl. 19:29, skrev Taylor Brandstetter:
>
> (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.
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------