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

RTCPriorityType combines relative bitrate with QoS priority, which applications may not want. #1625

Closed
taylor-b opened this issue Oct 10, 2017 · 9 comments
Assignees

Comments

@taylor-b
Copy link
Contributor

@taylor-b taylor-b commented Oct 10, 2017

This may really be an issue with https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/, but also may be a result of me interpreting it in a way other than intended, so I thought I'd raise the issue here first.

Anyway, 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.
  • 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 RTCPriorityType 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.

@taylor-b

This comment has been minimized.

Copy link
Contributor Author

@taylor-b taylor-b commented Oct 10, 2017

@aboba, any thoughts? We're starting to think about implementing this in Chrome, and realizing the problems with it. I see that it's marked as a feature at risk in ORTC, and wonder if these issues are part of the reason.

@aboba

This comment has been minimized.

Copy link
Contributor

@aboba aboba commented Oct 11, 2017

In general, I agree that the priority model is conflating too many things.

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.

  1. 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, nor any way of apportioning bandwidth between A/V/Data.

Also, SCTP implementations typically do not have pluggable congestion control or a way to share bandwidth estimates with RTP, 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).

  1. Conflation of priority and bandwidth allocation. In practice, an application may wish to allocate bandwidth and priority in different ways for different scenarios. For example, when using the data channel for a large file transfer within a video conference, the file transfer would typically be low priority - but it might end up taking up substantial bandwidth, particularly if A/V stopped expanding bandwidth before congesting the bottleneck . 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.
@taylor-b

This comment has been minimized.

Copy link
Contributor Author

@taylor-b taylor-b commented Oct 11, 2017

In practice, Windows only permits setting the DSCP code point on a per-socket, not per-packet basis.

Can't you use QOSSetFlow? From MSDN:

This function is also used to notify the QoS subsystem of a flow change: for example ... if the QoS priority value requires adjustment for transferring or streaming different types of content over a single persistent socket connection.

Or are there practical limits to this?

Does any other OS enable per-packet marking?

I thought POSIX OSes do, by calling setsockopt with IP_TOS or IPV6_TCLASS before sending the packet.

But anyway: even ignoring the issues related to QoS and multiple congestion controllers, it sounds like we agree that the "1:2" ratios are too limiting, and that mixing this up with QoS is undesirable.

@stefhak

This comment has been minimized.

Copy link
Contributor

@stefhak stefhak commented Oct 11, 2017

I think the problems and limitations both of you describe have been known since way back, but we (the rtcweb+webrtc community) accepted them (at the time) as good enough for v1.
If we have data supporting it is not good enough I guess an issue should be raised for https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/.

taylor-b added a commit to taylor-b/webrtc-pc that referenced this issue Oct 11, 2017
Fixes w3c#1625.

This provides more fine-grained control over the relative amount of bits
different encodings should be allocated. This allows the webrtc
implementation to respond quickly to changes in available capacity; the
alternative would be for an application to inspect the stats
periodically, and continually adjust `maxBitrate`, which would result in
wasted bandwidth and slower responsiveness to changing bandwidth
estimates (since polling stats and calling getParameters/setParameters
is not instantaneous).

This assumes that rtcweb-transports will update its definition of
"priority," such that it only controls the priority of streams in
network queues (via DSCP and SCTP priority values), and not the
relative amount of bitrate they're granted.
@taylor-b

This comment has been minimized.

Copy link
Contributor Author

@taylor-b taylor-b commented Oct 11, 2017

I'm adding this to the end of the interim topics, since it looks like we'll likely have some spare time at the end, and this will involve an API change if it goes the direction I expect it to.

@alvestrand

This comment has been minimized.

Copy link
Contributor

@alvestrand alvestrand commented Dec 1, 2017

WEBRTC accepted a proposal to split, but IETF RTCWEB rejected the proposal to modify the relevant rtcweb transport document.

Proposed resolution: Add an extension spec.
Proposed document: https://github.com/alvestrand/webrtc-dscp-exp

@aboba

This comment has been minimized.

Copy link
Contributor

@aboba aboba commented Jan 9, 2018

@alvestrand Now that we have the extension spec, can we close this issue?

@alvestrand

This comment has been minimized.

Copy link
Contributor

@alvestrand alvestrand commented Mar 8, 2018

I think we can close this issue now.

@alvestrand

This comment has been minimized.

Copy link
Contributor

@alvestrand alvestrand commented Mar 8, 2018

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