- From: Lennart Grahl <lennart.grahl@gmail.com>
- Date: Mon, 8 Jan 2018 17:01:42 +0100
- To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
- Cc: Bernard Aboba <Bernard.Aboba@microsoft.com>, Peter Thatcher <pthatcher@google.com>, thp@westhawk.co.uk, martin.thomson@gmail.com, public-webrtc@w3.org
>> On 6. Jan 2018, at 20:05, Bernard Aboba <Bernard.Aboba@microsoft.com> 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). >> >> 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. On 06.01.2018 20:35, Michael Tuexen wrote: > When specifying a CC for QUIC, it should be easy to specify it in a way it can > also be used in the context of SCTP. Possibly even for TCP. Thinking of BBR, for > example... > The SCTP stack of FreeBSD and the userland stack usrsctp already support multiple > congestion controls via a simple interface function call based interface. I think Tim said it very well: On 06.01.2018 15:08, westhawk wrote: > I agree standards take a while, but setting QUIC itself as a goal in the WG charter seems like putting the cart before the horse. > Prematurely latching onto an acronym rather than a set of desirable properties is how we got stuck on SDP IMHO. A charter shouldn’t specify a solution IMHO. So, why don't we just say that the charter of the WebRTC WG includes an intend to improve use cases where (large) reliable data transfers and a simultaneous audio/video session is required? Whether the solution is QUIC, or improving SCTP, or both, or whatever else can still be discussed. But as Bernard said, this probably should be discussed in some IETF WG. Cheers Lennart
Received on Monday, 8 January 2018 16:02:11 UTC