W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2018

Re: QUIC use cases

From: Justin Uberti <juberti@google.com>
Date: Thu, 18 Jan 2018 15:03:14 -0800
Message-ID: <CAOJ7v-0uxauPmwGp3Hgycg7EXpNwr3QP_P2LK752QwraSSuafg@mail.gmail.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: Lennart Grahl <lennart.grahl@gmail.com>, Peter Thatcher <pthatcher@google.com>, T H Panton <thp@westhawk.co.uk>, Martin Thomson <martin.thomson@gmail.com>, "dom@w3.org" <dom@w3.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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>

> 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 Thursday, 18 January 2018 23:04:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:38 UTC