Re: Call for adoption - WEBRTC-QUIC

>From a technical perspective, I'm not against having QUIC in the same
way I wouldn't be against any other transport protocol. From a web API
perspective, this seems to be just another secure data transport with a
slightly different API.

As far as I can see, adding QUIC (I'm talking about the transport here -
not the API) achieves what DTLS/SCTP could already do with a couple of
tweaks. But hold your breath...

Browser vendors already have (or will have) QUIC in the browser stack.
It is an in-house solution and they can easily hack on it, so it makes
sense to reuse it. I can relate to that.

There also seems to be a lack of interest in improving DTLS/SCTP for our
use case. BBR CC, pushing DTLS 1.3, Dropping an RTT from the SCTP
handshake, implementing and deploying SCTP-NDATA... all of this could be
done and would bring DTLS/SCTP (again, as a transport) at least to an
equal level. Yet, if I take a look at the involvement regarding usrsctp
which all browsers are using... there's virtually zero involvement
beyond occasional crash reports. That really puzzles me.

My issue with QUIC for WebRTC is the advertising (or the definition of
the problem to be resolved). I don't think it is about diving into
unchartered areas. This seems more about adding a very similar
technology whose main advantage is that browsers are heavily involved in
the development of it from the beginning. And, again, I can relate to
that. Yet, I'm slightly worried what happens if the lack of interest in
DTLS/SCTP hits QUIC as well... will we look for a new QUICER data
transport in that case?

On a compatibility note, I'm worried that implementations will ignore
DTLS/SCTP entirely and only deploy QUIC for data transmission.
Essentially letting us re-experience the "Apple and VP8" story again.

> [...] adoption as a WG document means that "we have consensus that there
> is a problem here that needs solving [...]
Can someone define "the problem that needs solving"? I'm definitely
seeing *a* problem (as stated above) but I have a hunch that it's not
the same problem others see.

Cheers
Lennart


On 20.11.18 09:57, Harald Alvestrand wrote:
> **
> 
> *From the Lyon summary of decisions:*
> 
> *
> 
> "The WG will ask the list if we should adopt the WEBRTC-QUIC API
> document (in room: 2 opposed, ~10 in favor)"
> 
> The question is whether we should adopt this document:
> 
> **https://w3c.github.io/webrtc-quic/
> 
> as a Working Group document
> 
> Adoption as a WG document does not mean commitment to any specific part
> of the API, or any specific timeline for processing the document to CR
> and beyond, but does mean that we can issue the document as a first
> public working draft (FPWD) and ask for IPR declarations (if any).
> 
> 
> My personal read is that adoption as a WG document means that "we have
> consensus that there is a problem here that needs solving, the problem
> is within the scope of this WG, and this document is a start on the way
> to solving it".
> 
> Non-adoption would indicate either that the problem shouldn't be solved,
> that the problem is out of scope for this WG, or that this document is
> so far away from the right solution that it's not a starting point the
> WG wants to consider.
> 
> 
> We are seeking both statements of support and statements of opposition.
> The chairs will tally the responses and attempt to draw a conclusion.
> 
> Please state your opinion to the**list on or before Wednesday, November 28.
> 
> Harald*,* for the chairs
> 
> *
> 
>

Received on Tuesday, 20 November 2018 18:46:18 UTC