Subject: Re: [quicwg/base-drafts] kInitialRtt of 100 msec is too aggressive (#2184)

From: Praveen Balasubramanian <[email-masked]>
Date: Mon, 25 Mar 2019 15:24:14 -0700

Please see  https://www.rfc-editor.org/rfc/rfc6298.txt Appendix A for a discussion of why the 1 second minimum was suggested for TCP. Based on data quoted there, 2.5% connections will experience spurious retransmissions if initialRTO < 1 second. Since QUIC will always get an RTT sample when handshake completes, we don't need any provision to reset the InitialRTT higher even if there were timeouts.

Orthogonal to this particular issue but a total timeout of 4 seconds (or anything less than 9 seconds) is going to be a problem for VM live migrations. It's assumed that the blackout period for live migration can last as long as 9 seconds because historically TCP would always retransmit at least once after 9 seconds. I guess its not a problem for browsers but if QUIC is used in other HTTP and non-HTTP libraries then connections will break during LM. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2184#issuecomment-476400711

---

From: ianswett <[email-masked]>
Date: Mon, 25 Mar 2019 15:51:19 -0700

Thanks for the additional information.  The data is from 2009(https://www.ietf.org/proceedings/75/slides/tcpm-1.pdf), but still seems largely plausible in terms of RTTs, though I'm sure some details have changed.

One thought is that the client may have a better idea of what it's RTT is than the server does when there is no resumption information available.  As such, we could pick a fairly conservative value(ie: 1s) on the server and if the client retransmits(and the server receives) the ClientHello more frequently,  the server should retransmit its response as well.  In practice, the current anti-amplification limit of 3x amount to exactly that in a lot of circumstances, so making it core to the handshake mechanism may be wise.  On the other hand, this is a special case unless we tweak the anti-amplification limit to be min(3 packets, initial server flight).

The 4 second timeout I mentioned is for the handshake.  I would expect live migrations to not occur during the handshake, or at least not expect the handshake to complete in that case, but maybe that's not true?  We experimented with bumping the timeout to 10 seconds a while back in gQUIC, but there were some performance regressions and we didn't dig in deeply enough to understand why.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2184#issuecomment-476407605

---

From: ianswett <[email-masked]>
Date: Tue, 26 Mar 2019 11:03:28 +0000 (UTC)

The discussion in Prague concluded that we should recommend 1 second to align with RFC6298 and clarify when previous RTT estimates should be expired(ie: upon network change) and when the persisted RTT associated with 0-RTT credentials should no longer be used(ie: upon network change).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2184#issuecomment-476577452

---

From: Loganaden Velvindron <[email-masked]>
Date: Tue, 26 Mar 2019 04:08:14 -0700

There are cases where the RTT is above 200ms. E.g From Mauritius to the US:

64 bytes from 208.95.3.4 (208.95.3.4): icmp_seq=1 ttl=48 time=370 ms
64 bytes from 208.95.3.4 (208.95.3.4): icmp_seq=2 ttl=48 time=387 ms
64 bytes from 208.95.3.4 (208.95.3.4): icmp_seq=3 ttl=48 time=411 ms
64 bytes from 208.95.3.4 (208.95.3.4): icmp_seq=4 ttl=48 time=492 ms
64 bytes from 208.95.3.4 (208.95.3.4): icmp_seq=5 ttl=48 time=506 ms
64 bytes from 208.95.3.4 (208.95.3.4): icmp_seq=6 ttl=48 time=370 ms
64 bytes from 208.95.3.4 (208.95.3.4): icmp_seq=7 ttl=48 time=410 ms

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2184#issuecomment-476579209