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

RE: QUIC use cases

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Mon, 15 Jan 2018 16:57:36 +0000
To: Lennart Grahl <lennart.grahl@gmail.com>
CC: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, 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: <CO2PR00MB0133EF0775D5A509B42CC804ECEB0@CO2PR00MB0133.namprd00.prod.outlook.com>
Lennart said:

"This is something that would be resolved by WHATWG streams for data channel messages... for RTCDataChannel there would have to be a stream for each message as data channels transfer datagrams and not a sequence of bytes.

Is it too much to ask for to at least go for the low-hanging fruits that wouldn't require a lot of effort? For example:

- fix the EOR bug when receiving data if you haven't fixed it already
- try larger SCTP window sizes for better throughput 
- activate ndata once it's available in usrsctp (if you're using usrsctp)

[BA] Fixing bugs, improving performance and adding support for additional SCTP protocol features are all good things for data channel implementers to work on.

Are there also things that the W3C WEBRTC WG should be doing?  For example, are there tests we should add to WPT and/or KITE framework, or issues in the RTCDataChannel API that need to be addressed? 
Received on Monday, 15 January 2018 16:58:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 15 January 2018 16:58:04 UTC