Re: QUIC use cases

On Fri, Jan 19, 2018 at 6:31 AM, Randell Jesup <randell-ietf@jesup.org>
wrote:

> On 1/19/2018 4:58 AM, T H Panton wrote:
>
>
> 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.
>
>
> 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).
>

If you are focused on this, the loading a page part can be very fast
(essentially zero if it is cached). P2P RTTs are largely out of your
control though; a brief review of our stats shows a latency distribution
with a very long tail, with the 95p over 500ms.

I am sure SCTP can be improved to get to the same RTT state as QUIC, but
QUIC supports this *now*, and so it provides another reason to explore QUIC
as an alternative. We can of course continue to improve SCTP in parallel.

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

Agreed.

>
>
> 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.
>
> Naturally we would expect to solve for this case as well in the future.