Re: Call for adoption - WEBRTC-QUIC

This is not the official position of anyone, including Google.

On Wed, Nov 28, 2018 at 9:23 AM Peter Thatcher <pthatcher@google.com> wrote:

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

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

I think that depends a good bit on what the scope of that API entails.  For
a real-time communication system scope, I do not believe that QUIC is
mature enough for good API design yet.  While I fervently hope we are done
with mucking around with the packet formats, I draw the attention of the
group to the stream states in section 3 of the QUIC transport document.
The alert reader will note that the document describes unidirectional and
bidrectional streams, but it does not describe partial reliability for
either. The document also does not describe multipath, despite support for
the degenerate case of path mobility.

Building an API for the scope of WebRTC's use of QUIC without those pieces
will, in my personal opinion, result in either enshrining naive methods for
managing them that will have to be maintained after the final methods are
built or in needlessly constraining the eventual design of those features.
Neither of those is a good result.  That the QUIC working group did not
finish its core deliverables and turn to these already is something I
regret (and I regretted the charter scope blocking parallel work from the
beginning), but the reality is that the WG could and likely will make
choices here we do not now anticipate.  Building an API without those
pieces being done is both risky and potenially destructive of working
relationship of the IETF and W3C in this space.

Note that this opinion is specific to this scope.  I believe that building
a Web API for QUIC as a distinct HTTP transport for resource retrieval
would not carry that risk and could be done now.

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

As a side note, I think this description of QUIC's design is an
over-simplification so blatant that I was somewhat shocked to see it.  A
multiplexing stream protocol is not as close to a raw UDP socket as you can
get, even in the context of what could ship in a browser.  If that's truly
what the web developer community wants, QUIC is far more heavyweight and
complex than their needs, and work to meet those needs should proceed
outside QUIC.

Again, my personal opinion only,

Ted

>