Re: QUIC use cases

> On 19 Jan 2018, at 06:47, Bernard Aboba <Bernard.Aboba@microsoft.com> 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.)
> 

To be clear, the RTT differences Justin is talking about are only for setup of a session. - Given we have to do a 
full OA exchange I'd guess only half the setup delay is due to those extra 4 rtts.

I'm open to discussing how that number could be reduced, but that's IETF talk I feel.

Within a session individual datachannels are 0RTT setup.
I don't think the RTT of messages to say an echo service would be different in QUIC than in DTLS/SCTP - In fact QUIC might be
slower since it has no message mechanism, which would need to be layered in.

Unless we move media to QUIC, we wouldn't see the benefit there since the current API has the SCTP keys being generated with 
DTLS as now.

T.

> 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.
>> 
>> 
>> 
>>