Intent to Implement: RTCQuicTransport & RTCIceTransport

386 views
Skip to first unread message

sham...@chromium.org

unread,
May 16, 2018, 6:41:37 PM5/16/18
to blink-dev

Contact emails

sham...@google.com, steve...@google.com, dead...@google.com, ptha...@google.com


Explainer

RTCQuicTransport & RTCIceTransport Expainer


Web API Specifications


Tag Review - This is being skipped until the extension specifications are more mature.


Summary

The RTCQuicTransport and RTCIceTransport APIs are both WebRTC extensions for exchanging P2P data and gathering ICE candidates. Unlike the PeerConnection RTCDataChannel, the QUIC data channel is a standalone API that allows the client to do their own signaling (not dependent on the SDP) and uses the RTCIceTransport to establish a P2P network connection. The underlying data transport protocol is QUIC, which has benefits of its own over the DTLS/SCTP stack used in a RTCDataChannel including faster connection establishment.


Motivation

It has been recognized by the WebRTC working group that web developers want lower level APIs (see discussion). Developers want more control over their code so that they can innovate. Without lower level APIs they are constrained by implementations, which means waiting on standardization, browser implementation and bug fixes. Allowing us to experiment with these features behind flags will provide valuable feedback for the much larger effort of the next WebRTC spec (2.0 or “NV”), which is currently in the process of being defined. The RTCIceTransport is one of the key pieces that is being discussed as part of the WebRTC 2.0/NV spec. The RTCIceTransport is of little use on its own, so it makes sense to implement it in tandem with a data channel.


Risks

Interoperability and Compatibility

Chromium will be the first to implement the RTCQuicTransport & RTCIceTransport, although the RTCIceTransport will be very similar to what is shipping in Edge (RTCIceTransport).


Web developers Developers are interested in lower level APIs and better data channels. Ideally, they would like to run audio/video/data over one transport- QUIC, and creating the RTCQuicTransport is a step towards providing this with the future WebRTC 2.0/NV components. QUIC has real-time friendly congestion control (BBR) which makes it advantageous to using SCTP.


Ergonomics

The RTCIceTransport isn’t useful by itself, and the RTCQuicTransport requires an RTCIceTransport for its underlying transport. The RTCIceTransport should be compatible with other WebRTC 1.0 endpoints, but note that currently this isn’t useful.


Activation

It should be relatively easy for developers to use this API quickly. Although additional code will need to be built on top of the spec to allow support for unreliable or message based data streams for media RTC. They will also need to provide their own self signed certificates (see PeerConnection.generateCertificate).


Debuggability

There shouldn’t be any changes to DevTools.


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

Yes


Feature Dashboard:


Requesting approval to ship?

No


Philip Jägenstedt

unread,
May 17, 2018, 3:54:22 AM5/17/18
to sham...@chromium.org, Alex Russell, blink-dev
I'd encourage you to request TAG review now rather than closer to shipping. The specs already look very spec-like, and TAG review is intended for the earlier part of the design process before everything is solidified. +Alex Russell, would you agree, in this case?

--
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/64134130-a62f-4f65-9561-fe735a34fd17%40chromium.org.

PhistucK

unread,
May 17, 2018, 5:03:14 AM5/17/18
to Philip Jägenstedt, sham...@chromium.org, Alex Russell, blink-dev
I doubt shipping this is near (in the long term sense), though. QUIC is currently only supported by Chromium and is not ratified.

☆PhistucK


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/CAARdPYd_zTYEeC8dU6yOS54APRFHeuO9nL_4aV8iszdwMwH7qA%40mail.gmail.com.

Harald Alvestrand

unread,
May 17, 2018, 1:06:54 PM5/17/18
to PhistucK, Philip Jägenstedt, sham...@chromium.org, Alex Russell, blink-dev
The QUIC effort in the IETF has been fairly robust in terms of implementation, with multiple implementations showing interoperability with each new draft version. So I'm not so worried about that.

I think this should be regarded as "exploratory engineering", though - if it turns out this approach doesn't work well in terms of either protocol efficiency or API ergonomics, we should be open to changing it.


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

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KJAuMtpY8Apx4-%2B8RN-Di72-61sHv5z2ZdcvvAs4Ar-A%40mail.gmail.com.

Philipp Hancke

unread,
May 18, 2018, 2:25:52 AM5/18/18
to Harald Alvestrand, PhistucK, Philip Jägenstedt, sham...@chromium.org, Alex Russell, blink-dev
I do think "web developers" would rather appreciate fixing https://bugs.chromium.org/p/webrtc/issues/detail?id=2276 -- it has only been open since 2013 while Firefox supported it all the time.

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

est...@google.com

unread,
May 20, 2018, 11:36:09 AM5/20/18
to blink-dev, h...@google.com, phis...@gmail.com, foo...@chromium.org, sham...@chromium.org, sligh...@chromium.org
Hi,
I'm doing security triage for blink-dev intents. This looks like a pretty big change, so if you weren't planning on it already, can you please follow the Chrome launch process (https://docs.google.com/document/d/1hJ1U8-7DNa7lGfTJWRgSgqQyNnOFO4Ks5Czr1-3--8I/edit, including design doc and security review) as well as the blink-dev intent process for this change?
Thanks,
Emily
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

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

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

sham...@chromium.org

unread,
Jul 26, 2018, 4:31:03 PM7/26/18
to blink-dev, h...@google.com, phis...@gmail.com, foo...@chromium.org, sham...@chromium.org, sligh...@chromium.org
Reply all
Reply to author
Forward
0 new messages