- From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
- Date: Fri, 19 Jan 2018 11:45:04 +0100
- To: Justin Uberti <juberti@google.com>
- 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>
> 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