RE: QUIC use cases

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: 

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. 

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.

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.

Received on Monday, 15 January 2018 05:03:55 UTC