Re: QUIC use cases

On 1/19/2018 4:58 AM, T H Panton wrote:
>
>> On 19 Jan 2018, at 06:47, Bernard Aboba <Bernard.Aboba@microsoft.com 
>> <mailto: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.

Yes, and we've talked about how to minimize overall setup time in the 
IETF by piggybacking some of the messages.  And as I said, games don't 
care; RTTs in setup have far more of an impact in "call" scenarios, 
especially PSTN-ish style calling (as opposed to meeting rooms) or PSTN 
gateways - time until the other side starts ringing.

In some data-only uses perhaps call setup time has an impact (connect, 
drop some data, disconnect, or on loading a page connect with 
datachannels to pull realtime data from something like a remote robot or 
stock market data or other realtime thing -- but the base "loading a 
page" part probably swamps this in most cases).

> Within a session individual datachannels are 0RTT setup.

*Very* intentional and I (and others) worked hard to get and retain this.

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

That would fall into the "implementation efficiency" bucket which will 
be swamped in most cases by network time -- and as you say it's unclear 
which would be better.  QUIC probably will get more eyes on 
optimization, at least eventually, but who knows, and I doubt it will 
matter.

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

   Randell

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

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam