Intent to Implement: Additional encodings.networkPriority field in RtpSender[Get|Set]Parameters

[Tim Haloun]

Contact emails

tha...@chromium.org, h...@chromium.org

Design doc/Spec

https://w3c.github.io/webrtc-dscp-exp/

Tag review in progress at: https://github.com/w3ctag/design-reviews/issues/325

Summary

WebRTC has expanded support for more flexible DSCP marking schemes, and we'd like to expose that functionality to the javascript layer.  Specifically, we'd like to enable scenarios where the DSCP values can be different between, say, audio and video, without affecting the local priority bandwidth allocations between them.  See https://tools.ietf.org/html/draft-ietf-rtcweb-transports-17#section-4.2 and cf https://tools.ietf.org/html/draft-ietf-rtcweb-transports-17#section-4.1 .

Here is the intent to implement with associated documentation for RtpSender parameters generally, that we are extending.

Motivation

DSCP support in chrome today is rudimentary, and controlled by the 'googDscp' Peerconnection constraint.  In practice, it results in all outbound traffic for that peerconnection using the AF_41 codepoint. By exposing this new field, we can achieve the table of values described in https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-18#section-5 allowing applications more control over the traffic they emit.

Risks

Interoperability and Compatibility

Low.  Different browsers support different subsets of RTPSender parameters and encodings parameters already.  The actual DSCP values on media traffic is expected to change or be stripped along the path between two clients anyway, and is currently not observed or exposed to the receiving client.

Since Firefox uses the same WebRTC library, it will eventually be able to expose the new parameter with little effort.

Ergonomics

No

Activation

No.  We will at first maintain the googDscp constraint guarding activation of any DSCP marking functionality.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.  Whether a particular system may not support applying TOS to the socket, however.

Is this feature fully tested by web-platform-tests?

SetParameters and GetParameters are partially tested:

https://github.com/w3c/web-platform-tests/issues/9395

https://wpt.fyi/webrtc/RTCRtpSender-setParameters.html

Link to entry on the feature dashboard

I think this addition is too small to merit this.

Requesting approval to ship?

Yes.  As mentioned before, the functionality is guarded by the 'googDscp' optional constraint and won't be enabled by default.

Thanks,

Tim

[Philip Jägenstedt]

Hi Tim,

Thanks for the offline poking. This wasn't flagged as requiring attention in https://bit.ly/blinkintents due to the title. Unfortunately even changing the title in subsequent emails doesn't change the name of the thread in the archives, so to make it clear for tracking, can you resend this with the title "Intent to Implement and Ship"? Sorry about the error-prone paperwork :/

For the tests, I see that networkPriority is not tested in web-platform-tests, can you make sure to add that together with the CL that eventually lands the changes? Thanks!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH-Wmdjsv3NnAGxcfvHTyr%2B5H2ZLLfR8VJ2LwQqoie19oeX6Sw%40mail.gmail.com.

[nohl...@mozilla.com]

Hi Tim,

Just to clarify: it is actually not true that it will be easy for Firefox to implement this feature as well.

While Firefox does use libwebrtc, we do only use a small part of it. Firefox has it's own signaling and networking stack.

Thus implementing DSCP marking in Firefox basically means we would need to re-implement the same feature in our code base.

Best regards

  Nils Ohlmeier

  Firefox Media Engineering Manager

[tha...@google.com]

Thanks Philip, will do.