- From: Justin Uberti <juberti@google.com>
- Date: Fri, 19 Jan 2018 08:49:18 -0800
- To: Randell Jesup <randell-ietf@jesup.org>
- Cc: public-webrtc@w3.org
- Message-ID: <CAOJ7v-3qYbWtPUv95-soLxFmMQvCRRKwPf0nO1AsOtuymBPGLg@mail.gmail.com>
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.
Received on Friday, 19 January 2018 16:50:04 UTC