Re: Call for adoption - WEBRTC-QUIC

On 28.11.18 18:21, Peter Thatcher wrote:
> 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).

I'm seeing that claim a lot on this mailing list... but solely on this
mailing list. I'll come back to that further down...

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

You might be jumping the gun here. I'm seeing three different parts that
the webrtc-quic draft contains:

1. A new API for data transmission not carrying the burden of the
WebSockets API. I'm definitely seeing interest in that area as can be
seen by the effort to creating a streaming API for data channels by
Jan-Ivar and myself.

2. Building transports on top of an ICE transport without SDP. I believe
there is interest in this WG for that, certainly for NV and maybe as an
extension (please correct me if I'm wrong). I would certainly be
interested in having that for RTCDataChannel, too.

3. Adding QUIC. This is the part that seems to be the most controversial.

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

We're being repetitively told that there are people who want it but at
least I haven't seen a lot of "why they want it" (apart from a few
mentioned below). And I believe that's an important question.

"We already have QUIC on our servers" seems reasonable.

There is also a use case popping up every now and then that requires
sync between media and data... but Tim already explained that this is a
transport agnostic problem.

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

Not sure how that's different to DTLS/SCTP.

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

This is something that bugs me when it comes to that argument: Why do we
compare DTLS/SCTP+RTP vs. QUIC-for-everything? IMO, the more fitting
comparison would be DTLS/SCTP-for-everything vs. QUIC-for-everything.
The only missing bit I see is a media-friendly CC... but pluggable CC in
(usr)SCTP is a thing.

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

Would they? "No one" is a bold claim. Others have done so.

Cheers
Lennart

Received on Wednesday, 28 November 2018 19:27:19 UTC