Re: Call for adoption - WEBRTC-QUIC

On Wed, Nov 28, 2018 at 11:04 AM Ted Hardie <ted.ietf@gmail.com> wrote:

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

The API at this point (the document as currently written) has nothing to do
with real-time communication.  It's purely a data transport.


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

The API at this point already has support for unidirectional and
bidirectional 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.
>

The design of the APIs should be an iterative process.  Nothing is being
"enshrined' for a long time away in the future.

We've been working on this for a year already, and iterated along with QUIC
features, such as successfully incorporated unidirectional and
bidirectional streams, and adding support for datagrams (in a PR).  I don't
think it will be that hard to continue to iterate along with QUIC as we
already have been.

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

We don't need to wait for the QUIC WG to finish everything to start on API
design, nor on getting implementation or developer feedback.  There is
plenty that we needed to figure out in parallel, and plenty we still do
while we wait for the QUIC WG to finish.

We've been doing this already for a year, and we're ahead of where we would
have been had we waited.  And I don't see any destruction of working
relationships going on, nor any risk of such.  In fact, we've being taking
things we learn in the W3C to feed back into the IETF, such as the work on
allowing QUIC to multiplex with ICE, DTLS, and RTP.


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

What's heavyweight about it?  If one sends many small QUIC streams that are
less than an MTU each, one ends up with something that looks like, on the
wire, almost exactly like UDP with security and encryption.  In fact, we
have an example of using it just like that in the QUIC API spec:

https://w3c.github.io/webrtc-quic/ (section 8)

We've used this approach in prototypes and it seems to work quite well
(with gQUIC at least, so far).

And if you use the (coming) support for datagrams, it's even more
lightweight (although not that much less):

https://github.com/w3c/webrtc-quic/pull/89/files



>
> Again, my personal opinion only,
>
> Ted
>
>>