Re: Call for adoption - WEBRTC-QUIC

Cullen said:

"I think the issue of how QUIC deal with non reliable data needs to be dealt with before we can use this for the data channel and it is a bit premature to adopt before we have that."

[BA] The existing QUIC transport supports the "one message per stream" model for partial reliability:
https://github.com/quicwg/ops-drafts/issues/15

The WebRTC-quic API has added support for unreliable transport (e.g. see: https://w3c.github.io/webrtc-quic/#dom-rtcquicstreamparameters ) based on this. To enable RTCDataChannel partial reliability to be fully supported, attributes such as maxRetransmits or maxPacketLifetime could be added to RTCQuicStreamParameters along with corresponding support in the underlying QUIC implementation.

The DATAGRAM proposal (see: https://tools.ietf.org/html/draft-pauly-quic-datagram ) can also be supported with a relatively minor change:
https://github.com/w3c/webrtc-quic/issues/77

Cullen also said:

"I also strongly feel that if there is a difference from server or P2P, we are doing it wrong - whatever we adopt should apply to both."

[BA] There are only minor differences, which relate to the constructor (which takes a URL for client-server rather than the RTCIceTransport used in P2P), the authentication model (client-server supports certificate validation rather than the self-signed certificates in P2P) and CORS (required for client-server). There are similar differences between the WebSockets API and the RTCDataChannel API.

An early draft of the client-server API can be seen here:
https://rawgit.com/w3c/webrtc-quic/client-server2/index.html

________________________________
From: Cullen Jennings <fluffy@iii.ca>
Sent: Monday, November 26, 2018 10:57 AM
To: Harald Alvestrand
Cc: public-webrtc@w3.org
Subject: Re: Call for adoption - WEBRTC-QUIC


I think the issue of how QUIC deal with non reliable data needs to be dealt with before we can use this for the data channel and it is a bit premature to adopt before we have that. I also strongly feel that if there is a difference from server or P2P, we are doing it wrong - whatever we adopt should apply to both. I think the solution should work for the media as well as the data channel over QUIC.



On Nov 20, 2018, at 1:57 AM, Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>> 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/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fwebrtc-quic%2F&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C45c39b89705841d2ee9208d653d1508f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636788555795098300&sdata=%2FUiuJegt%2F2iNqPB%2FZz09G39Z2193YCnD99LMeiB9JkQ%3D&reserved=0>

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