Re: QUIC use cases

Also:
4. 6 RTTs needed to set up ICE + DTLS + SCTP, vs 2 for ICE + QUIC.

On Sun, Jan 14, 2018 at 9:03 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
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:
>
> 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.
>
>
>
>