Re: Call for adoption - WEBRTC-QUIC

> 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 20:13:23 UTC