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

Re: QUIC use cases

From: Randell Jesup <randell-ietf@jesup.org>
Date: Fri, 19 Jan 2018 09:31:36 -0500
To: public-webrtc@w3.org
Message-ID: <36e53f71-882a-8e2b-c514-6984ae0351cf@jesup.org>
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 

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

Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam
Received on Friday, 19 January 2018 14:33:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:38 UTC