Re: Towards a new charter for the WebRTC Working Group

On 1/6/2018 2:05 PM, Bernard Aboba wrote:
> Lennart said:
>
> "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...  Is there a
> specific use case? Or is it just because the status quo of data channels
> is pretty 'meh'?'
>
> [BA] I have worked with developers currently using the SCTP data channel
> successfully in our UWP SDKs and have also received requests for QUIC support
> as well.
>
> So far, most of the SCTP data channel usage I see involves unreliable messages
> at relatively low bandwidth (e.g. in games).  The QUIC requests so far have involved
> a different use case - high bandwidth, reliable transferssimultaneous with audio/video sessions.

I've seen quite a few reliable datachannel uses (renegotiation p2p, file 
transfer, p2p akamai-type caching, side-stepping adblockers (ugh), etc)
Games typically will use a mixture of reliable and unreliable (or 
should) on different channels.

One reason high-speed filetransfer uses have suffered was the disconnect 
between the initial standard proposed (which allowed Websocket-length 
(effectively vm-limited) blob/array transfers), and the compromise 
agreed to (which limits the length of transfers, at least without 
ndata).  And ndata also avoids some annoying blocking in SCTP.

The other limiting factor is buffersize (for high-RTT/high-bandwidth 
connections, and probably very-high-bandwidth local connections), which 
thus far has been fixed, but nothing requires this.


> The file transfer use case has the potential to work better with QUIC than the SCTP data
> channel, assuming that the QUIC implementation supports pluggable congestion
> control so that the QUIC file transfer can use a delay-based algorithm rather
> than the loss-based algorithm used in SCTP implementations. This choice could
> potentially avoid building queues at the bottleneck (assuming that there were no
> other competing TCP/SCTP flows).

SCTP also has pluggable congestion control, and nothing mandates that it 
use the default AIMD-style. Our original discussions included a number 
of options to coordinate congestion control with the A/V channels (limit 
usage by SCTP to a specific fraction of the total if there's signs of 
congestion), and use alternate CC algorithms that are either delay-based 
or bimodal (delay-based but switch modes to a more aggressive posture if 
fighting TCP-ish congestion.  (And lots of other options).

To be clear: I don't see this as a fundamental advantage for QUIC or SCTP.

To a point made a while ago:
QUIC is cool.  It might make sense to use it for DataChannels.  But if 
so, we need to define a strong-enough set of requirements based on 
utility to the user of DataChannels that QUIC can meet and SCTP can't.  
Until we do that, any further work is premature.

Thus far, other than "cool", I see QUIC as having some advantage in 
avoiding an extra layer of protocol (and probably therefor bits) by not 
having SCTP-over-DTLS.  However, that's *way* below the bar to make such 
a change reasonable; that can only be a minor supporting point.  We also 
have to justify "do any proposed API changes to take advantage of QUIC 
features provide a major advantage to compensate for the 
complexity/interop cost?"

> However, since discussion of these use cases would require getting into protocol
> and transport issues (such as congestion control and loss recovery algorithms), it is
> probably better suited to an IETF WG (such as RMCAT) than the W3C.


Yes.  We (W3 WebRTC) should only be concerned with how it affects any 
web-facing APIs.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam