Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API for setting QoS priority of data channels #623

Closed
aboba opened this Issue Dec 1, 2016 · 5 comments

Comments

Projects
None yet
3 participants
@aboba
Copy link
Contributor

aboba commented Dec 1, 2016

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: w3c/webrtc-pc#955

aboba added a commit that referenced this issue Dec 1, 2016

@aboba aboba added the PR exists label Dec 2, 2016

@aboba

This comment has been minimized.

Copy link
Contributor Author

aboba commented Jan 11, 2017

@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

This comment has been minimized.

Copy link
Contributor

lgrahl commented Jan 11, 2017

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

This comment has been minimized.

Copy link

alvestrand commented Jan 12, 2017

@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

This comment has been minimized.

Copy link

alvestrand commented Jan 12, 2017

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

@aboba

This comment has been minimized.

Copy link
Contributor Author

aboba commented Jun 23, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.