W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > October 2017

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

From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
Date: Wed, 11 Oct 2017 00:17:00 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-335644494-1507681005-sysbot+gh@w3.org>
In trying to implement the priority model, there were a number of obstacles: 

1. Per-packet marking.  Section 3.1 states: 

   For UDP, this specification assumes the ability to set the DSCP code
   point of the sockets opened on a per-packet basis, in order to
   achieve the prioritizations described in [I-D.ietf-tsvwg-rtcweb-qos]
   (see Section 4.2) when multiple media types are multiplexed.

In practice, Windows only permits setting the DSCP code point on a per-socket, not per-packet basis.
Does any other OS enable per-packet marking?  This limitation implies that differential marking is only possible if Audio, Video and data channel use distinct ports, which is fairly rare in WebRTC applications.

2. Multiple congestion controllers.   If differential marking of bundled streams may not be practical, then perhaps we can use distinct prioritization/bandwidth allocation?  This is something we have implemented via a unified congestion controller.  However, prioritizing data channel versus audio/video is difficult if the data channel and A/V flows are using different congestion control/bandwidth limitation mechanisms.  There is maxBitrate for controlling the bitrate of sent encodings, but there is no equivalent for the data channel.  Also, SCTP implementations typically do not have pluggable congestion control, 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).  

3. Over-specification of bandwidth allocation.  In practice, an application may wish to allocate bandwidth in different ways for different scenarios.  For example, when using the data channel for file transfer, it might be desirable to allocate lots of bandwidth to the data channel, but that does *not* mean that the file transfer is high priority - quite the opposite in fact!  Similarly, for a game, data channel might be high priority (e.g. transmitting position within the game), but low bandwidth.  So yes, I agree that specifying a fixed ratio of bandwidth makes little sense.  


-- 
GitHub Notification of comment by aboba
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1625#issuecomment-335644494 using your GitHub account
Received on Wednesday, 11 October 2017 00:16:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 9 October 2019 15:14:55 UTC