Re: Call for adoption - WEBRTC-QUIC

Ted said:

"If you were starting from scratch at this moment, I might have different thoughts.  But this thread started with a call for the adoption of:

https://w3c.github.io/webrtc-quic/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fwebrtc-quic%2F&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C57d60fffadb74b455b6e08d65581b123%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636790412846629127&sdata=KTkTjnWD633em1vJCGjmmZt6MXLyCLLUKKrvb77qj1U%3D&reserved=0>

which proposes a design that already has made significant decisions.  Peter's message went on not to simply call for implementation cycles, but to note that some have already been completed.  My apologies if you feel that I have significantly misunderstood the state of play, but that did not indicate to me the blank sheets of paper we had six years ago."

[BA] While some of the basic goals<https://docs.google.com/presentation/d/1WOihY0SMJbWvfbc-41GA78F4yzPSwmyDOJ8GbRoU7dw/edit#slide=id.g44b656d873_73_425> have been stable, the WebRTC-QUIC specification has been undergone some major changes in the last few months, and that rate of change seems likely to continue, at least in the near term.

For example, the current draft of WebRTC-QUIC has changed substantially from was discussed at the WEBRTC WG meeting in Stockholm this summer (particularly with respect to the QuicStream object.  see: https://github.com/aboba/webrtc-quic for a snapshot of the previous version), in order to track changes in the QUIC transport, such as support for uni-directional streams.

Another major revision is being contemplated in order to support client-server scenarios (see: https://github.com/w3c/webrtc-quic/pull/73  ).

And beyond the major revisions, at TPAC Lyon, Peter proposed a redesign based on the WHATWG Streams API (see: "WHATWG-stream ALL the THINGS" starting at slide 60 of https://docs.google.com/presentation/d/1WOihY0SMJbWvfbc-41GA78F4yzPSwmyDOJ8GbRoU7dw/edit#slide=id.g44b656d873_73_528).

[cid:0593cf6f-43d9-463a-9844-e2b0b0244962]



________________________________
From: Ted Hardie <ted.ietf@gmail.com>
Sent: Wednesday, November 28, 2018 2:34 PM
To: Bernard Aboba
Cc: public-webrtc@w3.org
Subject: Re: Call for adoption - WEBRTC-QUIC

Dear Bernard,

On Wed, Nov 28, 2018 at 2:02 PM Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote:
Ted Hardie said:

"Building an API without those pieces being done is both risky and potentially destructive of working relationship of the IETF and W3C in this space."

[BA]  Thank you Ted for your extraordinary confidence in the efficiency of the W3C WEBRTC WG.  Given how long it has taken to get WebRTC-PC to Candidate Recommendation (6 years?), there are many who doubt the WEBRTC WG's ability to complete work in a timely manner.  Looking at the IETF QUIC WG Charter, the current estimate is that the QUIC Transport document will be completed by July 2019.  So the idea that the WEBRTC WG could guide WEBRTC-QUIC to completion (or even some level of stability) prior to that date (or even within a year or two of it) represents such extraordinary confidence in the WG that even sceptics lie stunned into silence.  To the doubters - no comments on "the triumph of hope over experience", please.

I am glad you recovered your voice so quickly.

If you were starting from scratch at this moment, I might have different thoughts.  But this thread started with a call for the adoption of:

https://w3c.github.io/webrtc-quic/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fwebrtc-quic%2F&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C57d60fffadb74b455b6e08d65581b123%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636790412846629127&sdata=KTkTjnWD633em1vJCGjmmZt6MXLyCLLUKKrvb77qj1U%3D&reserved=0>

which proposes a design that already has made significant decisions.  Peter's message went on not to simply call for implementation cycles, but to note that some have already been completed.  My apologies if you feel that I have significantly misunderstood the state of play, but that did not indicate to me the blank sheets of paper we had six years ago.

Of course, one could have made the same argument with respect to starting work on the WebRTC-PC API, since it depended on completion of work items within the IETF RTCWEB and other WGs, whose completion dates were uncertain. No doubt, had we waited until all RTCWEB WG work items were completed to begin work on the WebRTC API, the eventual result would have been different (and perhaps better).  Though there is the (minor) issue of what developers would have done in the interim.


Note that I said that creating an API with a different scope would be possible now; some decisions are well baked, even given the QUIC WG's radical openness to change.  I don't think that API scope matches the needed API scope for WebRTC, though, since WebRTC needs partial reliability and could use multipath.  Building the API now, when the relevant IETF working group both has not started is risky, and it is made more so by QUIC's openness to change.  When WebRTC and RTCWeb were chartered, it was done with a knowledge that the two had agreed on the remits of each group; I am not seeing a similar agreement here.  To me, that increases the risk.

If you were specifying a baseline API for QUIC as a new HTTP substrate you could avoid that risk, though I'm not sure why it would be done in this or other *RTC* W3C groups.

Again, my personal opinion and assessment.

regards,

Ted Hardie