Re: Call for adoption - WEBRTC-QUIC

On Mon, Dec 3, 2018 at 2:26 PM Cullen Jennings <fluffy@iii.ca> wrote:

>
> On Nov 26, 2018, at 12:32 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
> wrote:
>
> 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.
>
>
> But my impression was the QUIC WG did not view that as the right way do
> this.
>

The QUIC WG doesn't have a view on this.  Individual members of the QUIC WG
I have talked do about it think it's fine.


>
>
> 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.
>
>
>
> OK, but if they are minor, I think both version need to be defined in the
> same spec at same time and not leave one till the mythical "later".
>
>
> 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>
> 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 documentAdoption 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*
>
>