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

[tha...@chromium.org]

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.

See the previous i2i post for a bit of discussion: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/7SRh6Pl4iMA

[Philip Jägenstedt]

LGTM1 % web-platform-tests

Please make sure that there's more coverage of this in web-platform-tests. https://w3c.github.io/webrtc-pc/#dom-rtcprioritytype prescribes a specific mapping to the underlying layers. If it's not possible to test this in web-platform-tests without additional infrastructure, please file an issue at https://github.com/web-platform-tests/wpt/issues/new describing what's missing. (We can test HTTP, WebSockets, and HTTP/2 is being worked on, so it is possible.)

Nils Ohlmeier noted on the other thread that this isn't extra easy for Firefox to implement because they use libwebrtc, but would require some work.

Nevertheless, the interop risk appears quite low because of the nature of the API, which is providing hints about the priorities which even if missing entirely will not cause hard breakage. (That's not to say there are no risk, web developers may still tune their code for a specific browser and perform 10% worse on other browsers, but then the fix is ideally to specify in more detail what the effect of the hints are.)

--
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/8d4ab4d1-6006-4bd2-8215-e0d10a4aa2e5%40chromium.org.

[Rick Byers]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfLtDN5u0argzNzW5a4YAaAG-QaxN%3D4RmHnYp4h0R%2BbBg%40mail.gmail.com.

[Chris Harrelson]

LGTM3, but please do file a chromestatus entry. It is easy, and required for all changes. It also helps us to document changes in the next release.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-H9B--ys44gkbWs%2BOPhfs4JZANgRXmAXVJRwYjEtCVrA%40mail.gmail.com.

[tha...@chromium.org]

Done,

https://www.chromestatus.com/feature/5583278023114752

The form mentioned a launch bug as well?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

You don't need a launch bug.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-H9B--ys44gkbWs%2BOPhfs4JZANgRXmAXVJRwYjEtCVrA%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1a92ec60-78de-479e-bb1f-1c0f76142560%40chromium.org.

[Joe Medley]

I would have asked for one too. Not just because of what Chris said, but because of this:

"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."

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_GsgE1X%2BWD_2sVV-cs5C-e74ix0ECxxWjpnYZiar-ogA%40mail.gmail.com.

[Rick Byers]

On Thu, Nov 29, 2018 at 6:34 PM <tha...@chromium.org> wrote:

Done,

https://www.chromestatus.com/feature/5583278023114752

The form mentioned a launch bug as well?

We need to fix the wording on that form. The bug field is just SOME bug that people can see to track the progress of the work. Whatever (public) bug you're landing CLs against is fine.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.