Re: Call for adoption - WEBRTC-QUIC

FWIW, https://tools.ietf.org/html/draft-ietf-quic-transport-16 is an IETF
standards track protocol.

Overall, I do think we have the right experience and enthusiasm in this
group to pursue this work. However, if we want to reframe the effort
similar to what Youenn proposes, namely defining a protocol-agnostic NG
API, and then considering QUIC as one substrate on which this API can be
implemented (perhaps amongst others), that might facilitate reaching a
consensus here.

On Fri, Nov 30, 2018 at 2:07 AM westhawk <thp@westhawk.co.uk> wrote:

> Yep, that same Email from Magnus says:
> “
> At the interim it was planned to have a bit discussion on the datagram
> service for RTCWEB. The first question to try to resolve if there
> is consensus for including some form of non real-time media (i.e. not
> audio, video) service between peers. This is a bit tangled with the
> actual requirements and use cases. But there was views both for it and
> against it on the mailing list.
> So lets continue and try to come to a
> conclusion on this discussion.
> “
>
> As I recalled, there was some discussion. Also In that thread it was made
> clear to me that
> rtcweb was _strongly_ encouraged to reuse existing protocol work.
> I got substantial push-back on the idea of adapting existing (non IETF
> standard track)
> protocols for this use.
>
> (As a bonus to anyone who does the thread archeology - There was a very
> amusing Bot
> contributing high quality nonsense to the list at that point).
>
> My issue with the current QUIC proposal is exactly that it isn’t an
> existing protocol and
> that the requirements seem to me to be heavily server based and so out of
> scope for this group.
>
> Some of the proposed outcomes are desirable, but I’m unconvinced starting
> from ’there’ is the
> best way to achieve them.
>
>
> T.
>
> > On 29 Nov 2018, at 17:16, Justin Uberti <juberti@google.com> wrote:
> >
> > Here is a thread (from 2011) that discusses this topic. Of particular
> interest may be the goals enumerated in said thread, which sound like
> requirements for a generic data transport:
> >
> > - Unreliable data transmission
> > - Datagram oriented
> >    * Size limited by MTU
> >      - Path MTU discovery needed
> >    * Fragmentation by the application
> > - Low latency, i.e. Peer to Peer preferable
> > - Congestion Controlled, to be
> >    * Network friendly
> >    * Not become a Denial of Service tool
> > - Security
> >   * Confidentiality
> >   * Integrity Protected
> >   * Source Authenticated (at least bound to the signalling peer)
> >   * Ensure consent to receive data
> >
> >
> > On Thu, Nov 29, 2018 at 4:59 AM westhawk <thp@westhawk.co.uk> wrote:
> >
> >
> >> On 29 Nov 2018, at 13:23, Zhu, Jianjun <jianjun.zhu@intel.com> wrote:
> >>
> >> On 2018/11/29, 12:25 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote:
> >>
> >> That leaves me puzzled as to why this is the best WG to develop an API
> for it.  As a data transport for HTTP/3, it seems like this would be of
> broader interest within the W3C.
> >>
> >>
> >> Transferring data between peers is in WebRTC WG’s scope. I’m curious
> about was there any debate on adopting data channel.
> >>
> >>
> > As I recall, there was some debate. Our experience at that point was
> that adding data in a side channel was a good way to augment a call and
> that DTMF didn’t do it, nor would server routed websockets.
> > The data channel discussion was framed around area I think.
> >
> > Standalone data channel (with no associated call) came later and was a
> surprising success (at least to me).
> >
> > T.
> >
> >
> >
> >>
> >> Best Regards,
> >> Jianjun
> >
>
>