Re: Call for adoption - WEBRTC-QUIC

On Wed, Nov 28, 2018 at 9:23 PM Ted Hardie <ted.ietf@gmail.com> wrote:

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

I agree.  In my first message on this thread, I stated my opinion that the
non-p2p (client/server) parts should be done outside of the WebRTC WG and
the ORTC CG, because it's more than RTC.


>
>
>>
>>> 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 best way to find out is to get feedback from developers, which is what
we will be doing soon with an origin trial.  And it's good to do so now
rather than a year or two from now.


> 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 and when QUIC has partial reliability, that can be incorporated into the
API.  Until then, this simple mechanism works well enough.  And if this
simple mechanism ends up being unneeded, it could be removed.

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

Seems like a very minor one.


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

First, there hasn't been much coordination with the IETF needed thus far.
The only things that has been needed from the IETF has been related to
(de)multiplexing.  Everything else has been almost purely API work, not
protocol work.

Second, when we did need to coordinate, we did so in the appropriate WGs.
For example, to handle demuxing, Bernard and I (well, mostly Berndard :)
wrote a draft (
https://tools.ietf.org/html/draft-aboba-avtcore-quic-multiplexing-00) in
the AVTCORE WG.  We also discussed this with members of the QUIC WG to see
if we could get some bits flipped to make sure demuxing easier.

But we haven't needed anything from RTCWEB, so there hasn't been any need
for coordination with it.  Besides, I doubt the RTCWEB WG would have any
interest in this even if there were something it could contribute.



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