API for setting QoS priority of data channels

[aboba]

On 28 Nov 2016, at 22:50, Peter Thatcher pthatcher@google.com wrote:

Looking at draft-ietf-tsvwg-rtcweb-qos, it's clear we want to apply the very-low/low/medium/high priority to data channels. But we don't have any way in the WebRTC API, as far as I can tell, to set that priority.

Is this just something we forgot to add? If so, I propose that we add it as follows:

dictionary RTCDataChannelInit { ... RTCPriorityType priority; }

And it's meaning is defined by draft-ietf-tsvwg-rtcweb-qos.

WebRTC 1.0 Issue: https://github.com/w3c/webrtc-pc/issues/955

[aboba]

@pthatcherg @alvestrand Having added this to the WebRTC 1.0 API, and also having submitted a PR for ORTC, I must admit I am still a bit puzzled on how it would be implemented. My understanding is that existing operating systems (including Windows) require DSCP markings on a socket rather than on a per-packet basis. So TCP packets within a 5-tuple must be marked the same.

I realize that the priority attribute can also be used to influence relative priority (so as to influence bandwidth allocations to audio/video/data). However, the SCTP congestion control algorithm (which is typically loss-based and not pluggable) will intervene, and will compete with the video congestion control algorithm, and will (in the case of a loss-based algorithm) probably win.

So while I understand the desire to be able to assign relative priorities to audio/video/data, I'm having trouble imagining how this API can be implemented at full granularity.

[lgrahl]

I'm not actually sure if the priority of the data channel is meant as a priority relative to audio and video. The upcoming SCTP ndata extension will add per-stream priority values which we can use to prioritise data channels.

[alvestrand]

@aboba yes, TCP and DSCP markers must remain the same, because if the network discriminates, changing the DSCP marker invalidates the congestion control information. Advice from TSV, echoed in -rtcweb-transport:

All packets carrying data from the SCTP association supporting the data channels MUST use a single DSCP code point. The code point used SHOULD be that recommended by [I-D.ietf-tsvwg-rtcweb-qos] for the highest priority data channel carried. Note that this means that all data packets, no matter what their relative priority is, will be treated the same by the network.

All packets on one TCP connection, no matter what it carries, MUST use a single DSCP code point.

(I think we've accepted that adding a higher-priority data channel will corrupt congestion information, and we've decided to live with that.) So within a TCP or SCTP channel, local prioritization is the only effect from setting priority.

@lgrahi the priority of a data channel was intended to set the priority relative to audio and video, for the use of local decisions on "what to try to push next". A common congestion control across media and data is a holy grail of the RMCAT WG, but doesn't exist yet AFAIK. At the present state of our ignorance, I think local decisions on "what to send next" will have to be implemented - this means that one will have to send less data to a low priority data channel than SCTP says it can send when high priority video is throttled due to congestion. I'm not sure congestion is observable from the SCTP or RMCAT controllers to this degree - but it's all open source; in theory one can add the observability as needed.

[alvestrand]

note - local decisions can fix or alleviate self-congestion. The competition with other WEBRTC clients is a completely different topic.

[aboba]

@pthatcherg Looks like we overloaded RTCPriority for DSCP and data channel priority. See related WebRTC 1.0 issue: https://github.com/w3c/webrtc-pc/issues/1368