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

Re: Towards a new charter for the WebRTC Working Group

From: Lennart Grahl <lennart.grahl@gmail.com>
Date: Fri, 12 Jan 2018 13:27:32 +0100
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: Peter Thatcher <pthatcher@google.com>, T H Panton <thp@westhawk.co.uk>, Martin Thomson <martin.thomson@gmail.com>, dom@w3.org, public-webrtc@w3.org
Message-ID: <499ced35-1e73-dd07-ea66-49fba238ba86@gmail.com>
On 06.01.2018 20:05, Bernard Aboba wrote:
> 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). 

First of all, this is good feedback and it opened up the possibility for
others to jump in and propose solutions.

I want to come back to the 'Why?' for a second because I think it should
be absolutely crucial for us to find out what problems there are with
the current state of data channels when it comes to specific use cases.
Because many of the possible improvements may just as well be
low-hanging fruits for the existing API and for SCTP-based data channels.
By that I'm not saying we should only focus on improving SCTP-based data
channels rather than looking at QUIC. But if there are low-hanging
fruits regarding SCTP-based data channels, we should go for them as well.

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.

Received on Friday, 12 January 2018 12:27:57 UTC

This archive was generated by hypermail 2.3.1 : Friday, 12 January 2018 12:27:57 UTC