Re: Call for adoption - WEBRTC-QUIC

On 11/28/2018 1:03 PM, Ted Hardie wrote:
> This is not the official position of anyone, including Google.


And this is my personal opinion... for whatever that's worth, and I'd 
argue for it within Mozilla.

I agree strongly with Ted, and agree with his assertion that QUIC is 
very much not the equivalent of UDP-for-the-web.  It's built on UDP, for 
sure, but in many ways is comparable in complexity and functionality to 
SCTP-over-DTLS (details are different, but the fundamentals aren't that 
different at the 10000-foot view).  It certainly does have advantages, 
especially in the long run, over SCTP-over-DTLS, and can (eventually) 
cover more usecases.  But as Ted points out, there are holes in the 
functionality today, which would lead to ugly workarounds or dropping 
functionality.

I can see the argument that server SCTP-over-DTLS implementations are 
less common - but they exist.  People may not want to bother with them 
because they're not the new hot protocol-of-the-future, but that's not a 
strong enough argument IMHO.

Will QUIC get to where it can replace SCTP-over-DTLS (and other things)? 
Sure, I'll bet it will.  It isn't today.  Some parts, yes, but not all.

Note: I'm not a QUIC expert, but I also trust Ted's analysis here.

     Randell Jesup, Mozilla

>
> On Wed, Nov 28, 2018 at 9:23 AM Peter Thatcher <pthatcher@google.com 
> <mailto: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
>