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

Re: QUIC use cases

From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Date: Fri, 19 Jan 2018 11:45:04 +0100
Cc: Bernard Aboba <Bernard.Aboba@microsoft.com>, 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>
Message-Id: <96D402B3-DA13-4610-9ECF-BDBBCF68B632@lurchi.franken.de>
To: Justin Uberti <juberti@google.com>
> On 19. Jan 2018, at 00:03, Justin Uberti <juberti@google.com> wrote:
> 
> Also:
> 4. 6 RTTs needed to set up ICE + DTLS + SCTP, vs 2 for ICE + QUIC.
Will this still be true with DTLS 1.3? It is not difficult to extend
SCTP to allow 0 RTT connection setup in the context SCTP/DTLS, since
we don't need to cookie protection.

Best regards
Michael
> 
> 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.
> 
> 
> 
> 
Received on Friday, 19 January 2018 10:45:36 UTC

This archive was generated by hypermail 2.3.1 : Friday, 19 January 2018 10:45:36 UTC