Re: QUIC use cases

On 15.01.2018 06:03, Bernard Aboba wrote:
> Lennart said: 
> 
> "So, please, if someone tells you that data channels suck and they'd be
> excited to get QUIC data channels, please drill them with questions what
> sucks exactly and then post it on the mailing list or file issues."
> 
> [BA] The developers using SCTP for small unreliable file transfers seem satisfied overall (e.g. they just complain
> about bugs, not issues with the specification). 
> 
> The developers who have attempted to implement file transfers on SCTP data channels have encountered much
> more fundamental problems, including: 

Many thanks for going into detail here. I'd like to comment on some of
these problems.

> 1. Competition between SCTP data channels and audio/video, due to building of queues.  Currently, 
> data channel implementations use the default SCTP congestion control  (loss-based, defined in RFC 4960),
> and don't expose a way of selecting an alternative algorithm.  One developer I talked to expressed an
> interest in being able to use an algorithm like LEDBAT for a background file transfer, so I'm not clear
> that a new cc algorithm needs to be standardized in IETF.

I'm passing this on to Michael: Would it be feasible to do this with the
existing API of usrsctp?

> 2. Complexity of doing large file transfers on top of RTCDataChannel message implementations. 
> You've mentioned a number of the issues with this, and most of them seem solvable by fixing issues
> in the existing specification, and perhaps adding some tests to make sure that implementations conform
> to the new guidance.

Indeed, I believe one of the most pressing issues is the impact of
userland fragmentation/reassembly. I've written some tests a while ago
(Ops/sec * 10 yields Mbyte/s):

- https://jsperf.com/dc-fragmentation
- https://jsperf.com/dc-reassembly
- https://jsperf.com/chunked-dc-js-chunking
- https://jsperf.com/chunked-dc-js-unchunking

(Tests named 'naive' are not deployable from my point of view.)

This is something that would be resolved by WHATWG streams for data
channel messages (https://github.com/w3c/webrtc-pc/issues/1732).

> 3. Availability of multiple implementations.  I have heard complaints along the lines that Iñaki has
> described from other sources.  This isn't something the W3C or IETF can fix, but overall the perception
> in the developer community is that QUIC is very likely to be widely deployed and supported within 
> developer tools.  Several of the developers who had not been able to successfully utilize SCTP
> are now considering QUIC (using the client-server approach), and seem comfortable enough with the protocol
> and availability of tools that I doubt they would go back to considering SCTP data channels even with
> some of the above fixes. 

Yes, I think Iñaki raised a good point: Everyone rolled their own
SCTP-based data channel implementation and now we have a bunch of
implementations that are tightly integrated into a full WebRTC stack.
I'd say most of them are in need of some love and to me it looks like
priority is elsewhere. Hopefully we can help to improve this situation
by creating a dedicated library for data channels (see the other thread).

SCTP-based data channels are standardised for a long time now. I don't
want anyone to go 'back' to working with SCTP-based data channels...
they are already there. Is it too much to ask for to at least go for the
low-hanging fruits that wouldn't require a lot of effort? For example:

- fix the EOR bug when receiving data if you haven't fixed it already
(see: https://lgrahl.de/articles/demystifying-webrtc-dc-size-limit.html)
- try larger SCTP window sizes for better throughput (discussion:
https://bugzilla.mozilla.org/show_bug.cgi?id=1051685)
- activate ndata once it's available in usrsctp (if you're using usrsctp)

... or raise your hands if you'd be interested in using a data channel
library that does these things for you.

Comparing this to the effort required by adding a completely new
transport, I don't think that's too much to ask for.

Cheers
Lennart

Received on Monday, 15 January 2018 14:13:25 UTC