Re: Call for adoption - WEBRTC-QUIC

This is not the official position of Google, just my personal opinion.


TL;DR: I'm currently leaning toward recommending this:

1.  Client/server QUIC API work being done outside RTC groups, such as in
the WICG (in the short-term at least).

2.  p2p/RTC QUIC API work being done in the WebRTC WG if everyone wants to
work on it, and in the ORTC CG otherwise (with those who do want to work on
it).  Given the feedback on the list so far, it sounds like the ORTC CG
might make more sense for now, and the WebRTC WG can re-address adoption at
a later date.


And here's the longer answer:

I think this comes down to some facts:

1.  There is a lot of demand from developers for a Web API for QUIC, both
for client/server use cases and for p2p use cases (more demand for
client/server use cases).

2.  There is a lot of interest in doing the work (right now) to give
developers a Web API for QUIC, both among browser implementors and among
others in the web community.

3.  While QUIC may not be mature enough to call any such API "done" for a
while, it's  mature enough to start the design/impl/use/feedback iteration
loops necessary to arrive at a good API.

4.  Many of the design/impl iteration loops have already happened (from
which we've learned a lot and made good progress), and we expect
use/feedback loops to be coming soon as at least one browser launches an
early/experimental API for developers to try.

5.  There seems to be more interest in the API from non-RTC people than
from RTC people.  But the non-RTC people are scared away because the work
is in an RTC group and has an RTC prefix.  We've had a lot of people give a
reaction like "oh, WebRTC.... we don't want that.  Too complex".   They
would rather that work for the client/server parts happen outside of RTC
groups and without an RTC prefix.

6. We've been able to make fast progress in the ORTC CG on the API (much
faster than things seem to progress in the WebRTC WG) probably because it's
a small group all interested in QUIC.

Which leads me to two fundamental questions:

1.  Where should the client/server work happen?

I think the ORTC CG has been a fine place so far, but I think it should
move to somewhere non-RTC, perhaps starting in the WICG.   I believe this
is roughly Bernard's opinion as well.

2.  Where should the p2p/RTC work happen?  It can either remain in the ORTC
CG or move to the WebRTC WG.  It will likely move faster with a smaller
group in the CG and move slower but with a larger group in the WG.  So
which do we want?  faster/smaller or larger/slower?

If the entire WG were interested, it seems like it would be clear enough to
move from CG to WG.  But given the split between those interested and those
uninterested, perhaps it would make more sense for the p2p/RTC parts to
continue in the ORTC CG and for those interested to show up there.

See the TL;DR at the top for my recommendation.


Lastly, for those asking: "why QUIC?".   I have three answers:

1.  It's what developers are asking for.  They have it deployed on
servers.  They want web clients to connect to their servers and push data
and media to/from those clients.  They have it on their
mobile/native/embedded apps and they want to connect web clients to those
apps (p2p).  It's becoming the new substrate for everything and they want
the web to be a part of that future.  Once we've implemented this, it's
likely to be very popular.

2.  It's the closest thing to a raw UDP socket we can give web developers.
If we could give a raw UDP socket to web developers, everything (including
QUIC) could be done in JS/wasm.  But we can't.  We need to have security
(crypto) and congestion control.  And that's basically what QUIC is: UDP
with security and congestion control.  So, if we give them QUIC, we give
them the closest thing that many of them want.

3.  It's much more simple for RTC than DTLS+SCTP+RTP.  As a bonus, you get
audio, video, and data over the same congestion control context.  For
example, connecting a WebRTC web client to a server speaking
ICE+DTLS+SCTP+RTP is a major pain.  Few people even try.  But if RTC were
running over QUIC, it would be almost trivial.

As for SCTP: I want a solution that works for p2p and client/server.  If I
told the people asking for a client/server QUIC API to use SCTP instead,
they would laugh me out of the room.   No one wants to deploy SCTP on their
servers, especially after they've already deployed QUIC.  There are other
reasons, but that's the big one.  Besides it's not like we have to pick
one; we can have both.  They aren't mutually exclusive.