QUIC has been the source of all the heat during the internet meetings for the past two years at least, after being kind of restricted to a smaller group since its existence became known in 2013. There is a reason for that, QUIC as a transport protocol takes the best of TCP and the best of UDP, add encryption for security, multiplexing for speed, and bring additional improvements to make sure deployment will be fast on top of existing equipment, and updates (in user land) will be faster than before (in the kernel). For those interested in a first overview (possibly slightly biased as indicated in the respective sections) wikipedia is always a good start. For the hardcore Fans, the corresponding IETF working group and mailing lists will satisfy all your desire for detailed information. The latest drafts (#16), are hot out of the press as IETF 103 is ongoing in Bangkok this week.

Introduction

Even though you may think a transport protocol should be developed independently of the application running on it (the good old OSI model commitment), the history of QUIC is entangled with the one of HTTP/2 and the mapping of HTTP/2 on top of QUIC semantic is being evolved almost in parallel. Arguing of the need to converge in time for IETF 103, the QUIC working group actually requested the ongoing work to be restricted to that single use case. The subjects is hot, strategic, and a lot of money is involved, which surely explain the 16+ different implementation available today from several prominent actors of the internet.

The main apparent players behind QUIC are of course the web companies, but also and not surprisingly, the CDNs. Akamai is a big adopter of the technology and has employees as authors of many of the specs. 

The general media over the internet is de facto cut into two ecosystems: the broadcasting world and the real-time world. On the former, most of the distribution is file-based and HTTP based, and the focus on HTTP/2 over QUIC is logical. On the later most of the communications are RTP-based (RTSP/RTCP/SRTP/WebRTC/…). The exact same dichotomy is present within AOmedia with respect to AV1 for example.

There is a real question about RTP and QUIC that would require additional investigation: should we keep RTP for real-time media, or shall we drop it, knowing that some of the mechanisms in RTP will be redundant with those in QUIC? If we keep it, how do we map RTP on top of QUIC semantics and frames, and how do we multiplex all those protocols. If we drop it, how do we manage the mechanisms specific to media that are NOT in QUIC?

As usual in consensus driven group, one can request but not impose, and several groups and individuals with specific interest on (Real-Time) Media over QUIC have elected to spend their time on what was important to them, we can assume without any intend to delay the work of the QUIC group. 

Here are only the initiatives I am aware of, there are likely more.

A. Coming from ORTC, some have made an early implementation of a QUICTransport and a QUICStream whose code is available in the Chromium code base. The goal was to experiment with the transfer of data only and not media.

B. To prepare for more flexible pipelining in the media stack, as presented at the interim meeting in Stockholm, the Google team is pushing slowly more modular classes in WebRTC to allow one to bring its own encoder, encryption, media transport, network transport. You can also see work being done on a generic RTP packetizer ….

C. On a separate effort, The chairman of RMCAT working group collin perkins, which deals with among other things bandwidth estimation and congestion control, with another individual from call stats.io wrote a very interesting paper describing  in a very structured way the problems of both direct-media-over-QUIC and RTP-over-QUIC.

D. The AVTCORE group, who is in charge of everything RTP, is looking into the detail of multiplexing QUIC with all the other protocols RTP needs to support. The usual suspects are authoring this draft: peter T. from google (ORTC), Bernard A. from Microsoft (ORTC), and collin perkins mentioned before.

E. The TAPS working group is focussing on supporting QUIC as one of the transport of their protocol, and has reached out through the voice of pauly tommy (Apple) for feedback.

Bear in mind: every single one of those groups have a different end goal, and within some of the group you can also have divergences. The number of use cases for QUIC is equivalent to the number of use cases for UDP and TCP put together. Of course, for everyone, THEIR use case is the most important and should prevail.

Let’s take an example and list roughly the positions we can see emerging from the “webrtc ecosystem”?

Stop throwing new things in, finish 1.0.

This is the very explicitly stated position of many, including Apple. Different people have different reasons for that. The W3C working group is looking at the end of the current charter approaching fast (18 months), and the late implementation of unified plan and all the APIs needed for simulcast make testing simulcast difficult. As stated last week in Lyon: “Simulcast is a mountain whose summit elevation is unknown. We’re not only fighting an uphill battle, but we have actually almost no way to evaluate how long it’s gonna take.” For W3C staff, as well as the chairman and editor, this is a major concern. Apple and some other vendors would like to stabilise webrtc 1.0 as well, and some have expressed working on other things including QUIC as taking from the limited time of the Chairs and editors.

QUIC is simply not mature enough

has been the Mozilla position in the WebRTC group for all of 2018, expressed many times, but in particular during the interim face-to-face meeting in Stockholm in may, and at TPAC In Lyon two weeks ago. Those who disagree argue that the chair of the QUIC group, a Mozilla employee, is aiming at Q4 2018 for standard documents, and that other group should not wait too much to investigate what it would take to adopt it, so the decision about wether the WebRTC working should adopt it or not be an informed decision. For others, QUIC is already happening and if the webRTC group does not make its own decision, it will be made for them. (Same argument has been brought forward for SVC codecs.)

There seems to be a consensus from all parties involved anyway that an unreliable mode (more UDP than TCP behaviour) would be needed for media over QUIC, which is not on the table today. The latest unidirectional QUIC streams have also broken a few things.

My techno that I love is working, I wrote the library, do not replace it by anything, ever …

It is human nature to push back against changes, and it should be expected here again. The investment to reach the level of expertise to participate in the WebRTC standard and its implementation is important, and the time spent by some on writing a software project, their project, THE project, make some very emotionally involved.

Different people express their emotions in different way, between blind reject, to cautious reject. It usually translates into “There is no reason to stop using my techno” to “I’m waiting to see a real use case that would justify moving away from something that works today.” Except that, there might never be any use case other than consolidation of underlying protocols, or “X decided so”, X being a sufficiently powerful entity to make it happen in any case.

My personally point of view is slightly more nuanced, but I stay on the side of caution:

• QUIC is the future, we could delay it, but we can’t avoid it. So was WebRTC at one point.
• moving directly away from RTP would leave a LOT of existing webrtc infrastructures without any interoperability capacity. This is, IMHO, too brutal an approach. The team behind QUIC had originally spent a lot of time to put into the design practical choices so that QUIC can be an incremental enhancement of current techno (UDP based), to be sure the adoption could be fast. I’m trusting them to have the same practical approach for Real-Time Media Over QUIC. Here, I hope the feedback from webrtc Media Server implementors will be taken into account.
• The compromise could be to provide both choices, i.e. an update path for existing RTP infrastructure with an implementation of RTP over QUIC, while proposing real-time media over qui directly for those who want it (native apps, …)
• Note that WebRTC 1.0 is not going away, so one will always be able to generate and consume (DTLS-S)RTP streams, as well as SCTP streams. 

Conclusion:

I think we illustrated that even within WebRTC, there are several opinions when it comes to QUIC. If you add all the other opinions from all the other groups involved in QUIC, some of them cited above, that makes a lot of people trying to be the captain and move the boat in a different direction.

Both IETF and W3C are consensus-based organization, to a different degree. No opinion is ever suppressed, everybody is free to open ticket, ask questions on the mailing list, and to request time in the agenda during the meeting. You will be heard and read. However, you need to manage your expectation about your capacity to do anything beyond that.

You would need to rally enough people to your opinion to reach a consensus, and that’s a time consuming task, which require specific, non-technical skills. You need to convince people your point is not only valid, but worth of them spending their time on it. Basically you have to go around and convince everyone what you propose is better FOR THEM. That means you need to invest the time first to understand what they want, and what they don’t want, and take this into account in the final proposal so their interests are aligned. You need to create goodwill. This is more diplomacy than technology.

If your scope is too narrow, you will not have enough people to reach the critical mass. If you do not compromise, ditto. If you ask other people to spend time to help you (find use case, prove you wrong/right, ….) they won’t. They already for most do not have time enough to deal with everything they need to do. Most of this work is done in parallel of the meeting and constitute the core difference between those actually attending the meetings in the flesh, and those attending remotely.

One clear sign of failing “diplomacy” is when nobody answers your e-mail or your questions. Only the editors and the chairs have the duty to answer, however, the activity generated in the different official venues (GitHub of the spec, mailing list, meetings in the case of WebRTC), is a good proxy of the interest of the group and/or the potential for consensus to the chair/editors to base their decision on. 

Mozilla’s Adam roach has always been my model there, and you can see some of its skills in action here:

“the hallmark of a good compromise is that nobody leaves happy, but everyone can force themselves to accept it”