Re: QUIC use cases

> On 15. Jan 2018, at 15:13, Lennart Grahl <lennart.grahl@gmail.com> wrote:
> 
> 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?
The CC (there are multiple implemented) in usrsctp are implemented in a single file.
They can be selected on a per association base. However, LEDBAT is currently not implemented.
But it could be done. Most CC's are not tied to a specific protocol.

Best regards
Michael
> 
>> 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 19:16:22 UTC