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

RE: Towards a new charter for the WebRTC Working Group

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Sat, 6 Jan 2018 19:05:05 +0000
To: Lennart Grahl <lennart.grahl@gmail.com>, Peter Thatcher <pthatcher@google.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>, "thp@westhawk.co.uk" <thp@westhawk.co.uk>, "martin.thomson@gmail.com" <martin.thomson@gmail.com>, "dom@w3.org" <dom@w3.org>
Message-ID: <CO2PR00MB01359F263464337DF40AAB81EC1D0@CO2PR00MB0135.namprd00.prod.outlook.com>
Lennart said: 

"Just saying "QUIC is better than SCTP over DTLS" is
obviously not enough. I think there needs to be a document clarifying
these questions in detail available to everyone...  Is there a
specific use case? Or is it just because the status quo of data channels
is pretty 'meh'?'

[BA] I have worked with developers currently using the SCTP data channel
successfully in our UWP SDKs and have also received requests for QUIC support
as well.

So far, most of the SCTP data channel usage I see involves unreliable messages
at relatively low bandwidth (e.g. in games).  The QUIC requests so far have involved
a different use case - high bandwidth, reliable transferssimultaneous with audio/video sessions. 

The file transfer use case has the potential to work better with QUIC than the SCTP data
channel, assuming that the QUIC implementation supports pluggable congestion
control so that the QUIC file transfer can use a delay-based algorithm rather
than the loss-based algorithm used in SCTP implementations. This choice could
potentially avoid building queues at the bottleneck (assuming that there were no
other competing TCP/SCTP flows). 

However, since discussion of these use cases would require getting into protocol 
and transport issues (such as congestion control and loss recovery algorithms), it is
probably better suited to an IETF WG (such as RMCAT) than the W3C. 
Received on Saturday, 6 January 2018 19:05:33 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 6 January 2018 19:05:34 UTC