Re: QUIC use cases

On 1/19/2018 1:47 AM, Bernard Aboba wrote:
> Games developers are obsessed with latency, so RTT reduction is a big 
> deal (along with better tools). However they also need control of 
> maxRetransmits (often set to zero). Saying that is out of scope for 
> QUICv1 elicits puzzled expressions. In fact, the whole idea of version 
> negotiation in a transport protocol makes no sense to them (e.g. no 
> version negotiation in TCP, SCTP, DCCP, etc.)

Delay reduction is important in games -- but initial setup time is far 
less so.  Not of no interest, but rarely if ever an issue for I'd guess 
99% of online games.  Only (largely) p2p games that dynamically create 
connections in fairly hard realtime (as people move around a larger 
universe) would be affected, and that's pretty rare even in 
non-browser-based games (I can think of 1). controlling retransmits *is* 
very important, as is multiple independent channels with different 
characteristics.

    Randell

>
> On Jan 18, 2018, at 3:03 PM, Justin Uberti <juberti@google.com 
> <mailto:juberti@google.com>> wrote:
>
>> Also:
>> 4. 6 RTTs needed to set up ICE + DTLS + SCTP, vs 2 for ICE + QUIC.
>>
>> On Sun, Jan 14, 2018 at 9:03 PM, Bernard Aboba 
>> <Bernard.Aboba@microsoft.com <mailto: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.
>>
>>
>>
>>