Re: Call for adoption - WEBRTC-QUIC

Some comments in-line, purely as an individual.

On Wed, Nov 28, 2018 at 7:05 PM Peter Thatcher <pthatcher@google.com> wrote:

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

That leaves me puzzled as to why this is the best WG to develop an API for
it.  As a data transport for HTTP/3, it seems like this would be of broader
interest within the W3C.


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

You may be further along, but it's not clear to me whether we can tell yet
whether it is along the right road.  In your reply to Cullen, you said:

The API already (at https://github.com/w3c/webrtc-quic) already has support
> for unreliability.  It's a simple mechanism: just don't send retransmissions
>

Section 8.1 contains little more:

Unreliable delivery can be achieved by creating many streams with
> retransmissions disabled, each transporting a single small message
>

That potentially conflates three different states which may mean different
things to specific congestion controllers or applications:

1) There was loss along the path.
2) There was re-ordering such that data which arrived was elided before
being transmitted to the application.
3) There was data which arrived in order but the  application did not
consume the stream (e.g. in K of N FEC schemes, where K had already been
received).

The iETF work on partial reliability may, in other words, produce
requirements or states which do not match this API's presumption that
simply disabling the retransmission is enough.  If QUIC stacks have to
support it anyway because it has been widely deployed in advance of the
work on the reliability model, that's either a cost or a risk, as I laid
out before.



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

I believe that the charter of the WebRTC was built with the expectation of
a split of work this document does not share.  The document currently says:

"This work will be done in collaboration with the IETF. The W3C will define
APIs to ensure that application developers can control the components or
the architecture for selection and profiling of the wire protocols that
will be produced by the IETF Real-Time Communication in WEB-browsers
(RTCWeb) Working Group."

Given the impending closure of the RTCWEB working group, I do not blame you
for not wanting to coordinate with RTCWEB on this, nor with declining to
put RTCWEB on the critical path.  But setting up a similar relationship
with QUIC seems to be both common courtesy and common sense.  QUIC has a
very clear charter element on this:

"Extensions that will support partial reliability, and negotiation
and use of Forward Error Correction schemes, are out of scope in
this version of the working group charter."

This proposes to create APIs for something that QUIC says does not yet
exist.  Given this text in the W3C WG charter:

"The definition of the network protocols used to establish the connections
between peers is out of scope for this group; in general, it is expected
that protocols considerations will be handled in the IETF."

That does seem to be damaging to me, absent a change in the IETF WG's
charter.  I haven't seen any moves toward that from the proponents on the
QUIC list, on the IESG list, or any of the other places I might expect that
coordination to occur.  If I have missed it and this is agreed, please
accept my apologies and provide me a pointer to the discussion so I can
read up on what I missed.  If that has not occurred, though, I think the
coordination with groups defining the network protocols should occur before
adopting the work on the API.

I agree with both you and Bernard that doesn't mean "wait for everything to
finish before starting the API".  But my personal opinion is that the
signals that something is stable enough to construct APIs for should come
at least partly the advice of the people specifying the network protocol.
That's the heart of the coordination, with this split of tasks.


>
>> 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:
>
> I think you and I  have a different impression of how well that mimics
what a raw UDP socket would be.


> 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
>>
>
As noted above, this is my personal opinion only.

regards,

Ted