Re: Call for adoption - WEBRTC-QUIC

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
>

Received on Friday, 30 November 2018 10:08:07 UTC