Re: Call for adoption - WEBRTC-QUIC

These requirements are from 2011. The point here was to point out that we
previously deemed that WebRTC was an appropriate forum to build a generic
p2p data transport, and we seem to have done a very good job of it, so this
is as good of a venue as any to do any future work.

Of course, in 2018, we have new requirements, which others have pointed out
(e.g., breadth of implementations, 0-RTT, combined media/data CC). There
are many possible ways we can approach these requirements, and we can try
more than one. Regardless, I think the QUIC proposal seems to address the
old and new requirements, and as such is worth pursuing.

On Thu, Nov 29, 2018 at 12:12 PM Michael Tuexen <
michael.tuexen@lurchi.franken.de> wrote:

>
>
> > 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
> Am I missing something or aren't the above requirements fulfilled by the
> SCTP-based data channels?
>
> Best regards
> Michael
> >
> >
> > 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
> >
>
>