Re: Call for adoption - WEBRTC-QUIC

> On 29. Nov 2018, at 21:50, Justin Uberti <juberti@google.com> wrote:
> 
> 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.
Ahh, OK.
> 
> 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.
If wanted, we can also improve the SCTP based data channels (0-RTT seems the be a low hanging fruit),
CC is most of the time transport protocol independent. Managing RTP over SCTP streams seems similar
to RTC over an extension of QUIC...

So if it is clear what to do, one can evolve the SCTP based data channels in that direction.

Best regards
Michael
> 
> 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
> > 
>

Received on Thursday, 29 November 2018 21:25:51 UTC