Re: Towards a new charter for the WebRTC Working Group

On 06.01.2018 01:57, Peter Thatcher wrote:
> On Tue, Jan 2, 2018 at 3:47 AM T H Panton <thp@westhawk.co.uk> wrote:
>>> On 2 Jan 2018, at 05:26, Bernard Aboba <Bernard.Aboba@microsoft.com>
>> wrote:
>>>
>>> Martin said:
>>>
>>> "What are the plans for the protocol pieces for the new items?  I
>>> haven't seen any plans - or internet-drafts - for those, and the bulk
>>> of the work for some of these items is protocol work.  For instance, I
>>> can understand why the group might choose not to rely on SDP for
>>> negotiating new features, which leads to some API work, but the bulk
>>> of the QUIC datachannels work is in defining protocols, not the API."
>>>
>>> [BA] The QUIC API presented at TPAC depends only on currently chartered
>> work in the IETF QUIC WG (e.g. the QUIC transport document) as well as
>> resolution of the QUIC multiplexing problem (by whatever approach the IETF
>> decides on).
>>>
>>> As the QUIC transport document evolves, the QUIC API will presumably
>> evolve as well (e.g. the proposed API currently provides a bi-directional
>> stream abstraction).
>>>
>>> As Peter noted, it should be possible to implement the RTCDataChannel
>> API on top of the proposed QUIC API once the IETF defines the protocol for
>> QUIC datachannels.
>>>
>>
>> I don't think I've seen the requirements/use-case doc for QUIC - or indeed
>> any discussion about why only QUIC will do whatever the need is.
>> If we are picking a new protocol we should be _super_ clear why.
>> The current multilayer protocol soup at least has the advantages that each
>> ingredient is reasonably well known and
>> well specified. Most of them have multiple tested public implementations.
>>
>> This is useful in 2 ways:
>> 1) it makes the spec possible to implement in a reasonable timeframe.
>> 2) it makes it relatively easy to handwave about the security properties
>> of the stack.
>> e.g: "You were going to use x over DTLS - this is just the same, but has
>> ICE support and works in a browser"
>>
>> Given that we haven't implemented 1.0 anywhere yet, I'm a bit negative
>> about 2.0 including a load of new untested stuff
>>
> 
> It sounds like you're making three completely different arguments:
> 
> 1.  Something like "let's not do any 2.0 stuff until all the 1.0 stuff is
> implemented".
> 
> 2.  Something like "let's not do any untested things in 2.0, and QUIC is
> untested".
> 
> 3.  Let's only do things unless we have good reasons.
> 
> 
> I don't agree with  #1.  If we wait until all the browsers are done
> implementing all of 1.0 before we standardize anything else, we'll be
> twiddling our thumbs for a long time in the WG and wasting valuable time.
> The standardization process takes a long time, so we might as well start
> now on work that will take a while rather than waiting until much later.
>  We should do something with the time we have, but not sit around doing
> nothing while implementations catch up.

Basically, I agree with you. However, I don't want to see people using
that as an excuse to not fix their SCTP-based data channels (or even
implement/activate them)... this is how it looks to me right now.

> I don't agree with #2.  While the QUIC that's coming out of the QUIC WG is
> untested (since it's not done), the pre-draft version of QUIC out in the
> while is very tested and used very widely in production.  In what sense is
> QUIC untested?
> 
> I agree with #3, and I think there are good reasons to do QUIC data
> channels.  It's is one of the most common things that people ask us to put
> in Chrome (in relation to WebRTC).  And it's the "2.0" thing that's gotten
> the most interest from the WebRTC WG (amongst ORTC, QUIC, and Cullen's
> low-level ICE idea)
> 
> I could go into more specifics, but there are lots of reasons why QUIC data
> channels are better than SCTP ones.  And that's the big reason: QUIC is
> better than SCTP over DTLS.

To cite Tim:

"I don't think I've seen the requirements/use-case doc for QUIC - or
indeed any discussion about why only QUIC will do whatever the need is.
If we are picking a new protocol we should be _super_ clear why."

^ This. Even though I'm very excited about new technology (and QUIC
certainly is very interesting), I'd also like to know that as a base for
further discussions. Just saying "QUIC is better than SCTP over DTLS" is
obviously not enough. I think there needs to be a document clarifying
these questions in detail available to everyone.

You said that QUIC data channels are the most common thing that people
ask you to put in Chrome. So, what makes them say that? Is there a
specific use case? Or is it just because the status quo of data channels
is pretty 'meh'?

Furthermore, I want to add something I've mentioned before: Let us put a
streaming API for data channels on the agenda for 2.0. If we want to
support sending large datagrams (and we want that - the SCTP ndata
extension has been mainly written for that purpose and I'm pretty sure
QUIC supports interleaving of streams, too), we will need some sort of
streaming technique. We can use WHATWG streams where each datagram is a
stream and I have an idea how this would not even break API.

Cheers
Lennart

Received on Saturday, 6 January 2018 12:46:14 UTC