Subject: [quicwg/base-drafts] kDefaultInitialRtt too large (#752)

From: Lars Eggert <[email-masked]>
Date: Tue, 29 Aug 2017 06:39:59 +0000 (UTC)

Opening this for @huitema, who on Slack said:

> kDefaultInitialRtt (default 100ms):
>    The default RTT used before an RTT sample is taken.
>
> That's seriously optimistic. If there were direct fiber path everywhere, 100ms would be enough for 20,000 km, half the Earth circumference. But there are not that many fibers, and intercontinental ping times are more like 150-200 ms. And of course a satellite ping is 300 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/752

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Aug 2017 05:49:56 +0000 (UTC)

I don't know whether this is a value that needs to be larger than any known path, or just typical.  I don't know how you could measure "typical", but there you have it.

I know that big providers see much lower RTTs than this because they are typically close to all of their clients, so a smaller value here does give them a small advantage.  And big providers dominate our telemetry, so it's hard to know.

For reference, I have a ping of 48ms to Google and Bing (both of which are probably about 20km away), 250ms to GitHub (which appears to be on the other side of an ocean), Yahoo is at 360ms, duckduckgo is around 400.  Facebook wins at 45ms, but it's really erratic.

-- 
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/752#issuecomment-325888670

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Aug 2017 07:03:33 +0000 (UTC)

TCP uses 3 seconds here. I don't think we need to be quite as large, but I'd use at least 1 sec. 

-- 
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/752#issuecomment-325901643

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Aug 2017 10:26:23 +0000 (UTC)

Can you provide rationale for the number?  That is probably more than most terrestrial connection will ever see for an RTT (yeah, I've heard the horror stories of RTTs higher than that, but those are outliers).  That suggests that you want something higher because of reasons.  What TCP does it isn't especially informative, frankly.  That TCP has good reasons for the number it chose would be a fine reason to pick a similar number; are those reasons written down anywhere?

-- 
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/752#issuecomment-325950021

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Aug 2017 11:31:27 +0000 (UTC)

If you're too short, many (?) clients will do an unnecessary RTX of the CH. If you're too long, however, only those (few?) hosts whose CH is lost will wait a bit longer to RTX. So the tradeoff is between many (?) unnecessary retransmits vs.  a longer wait time for those few (?) whose CH is lost. A shorter initial value potentially wastes some bandwidth, a longer potentially leads to longer page-load-times for a few. Pick your poison. I think the IETF in the past has valued bandwidth over PLT.

-- 
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/752#issuecomment-325963252

---

From: Patrick McManus <[email-masked]>
Date: Wed, 30 Aug 2017 13:24:35 +0000 (UTC)

> I think the IETF in the past has valued bandwidth over PLT.

For QUIC - I think that's backwards.

QUIC has already made the latency over bw trade with the CI by using a 1200 byte CI instead of a 3 way handshake. I'd like to think that the CI is a small fraction of total quic bandwidth and this is worthwhile.

We've seen applications (especially http applications) push back against the historical TCP situation in a number of places even in a TCP context.. showing that the tradeoff wants to favor latency.

* for years chrome and firefox have both started a new TCP connection when a previous connection attempt has not yet connected after ~300ms. This is to workaround the 3 second OS level timer - which is considered too high of a delay especially when you're otherwise staring at a idle spinner. And yes, that commonly results in 2 completed connections without any TCP level retransmissions - but in the grand scheme of things a couple of packets is a nop but the benefit is significant.

* chrome, firefox, and edge commonly initiate tcp connections before they have any http data to send on them (perhaps this is done totally speculatively, perhaps it is done by opening N when you only need 1 at the moment.. in anticipation). Mostly this is done for latency purposes - get the tcp and tls handshakes out of the way so they are ready for http data when it happens  (some of it can go away when we think 0rtt quic would work instead). Many of these connections close without ever transferring meaningful data - but that's a latency over bandwidth tradeoff (and the bandwidth consumed is small enough in comparison that it doesn't meaningfully impact the real data transfer that goes on).

* TCP PLT, default on in linux distributions, is another illustration of http applications willing to trade off some wasted retransmissions against the tyranny of large timers.

Also worth nothing that enabling fec extensions is within the wg charter (although doing them is not) - and fec is the ultimate in latency over bandwidth tradeoff but much harder to get right than the redundant control traffic we're talking about here.

-- 
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/752#issuecomment-325988912

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Aug 2017 13:58:07 +0000 (UTC)

> For QUIC - I think that's backwards.

I tend to agree, that's why I phrased it this way. But I also think that 100ms is too short. If 300ms has proven an OK value for TCP for browsers, that might be a good candidate value here? It would cover most terrestrial paths.

-- 
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/752#issuecomment-325998700

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 30 Aug 2017 13:59:07 +0000 (UTC)

We have RTT data from Chrome which shows that the initial RTT distribution:

PercentileValue
25.00% 22.58
50.00% 46.28
75.00% 88.08
95.00% 240.0
99.00% 733.9
99.50% 1187

>From this table, 100ms looks like a fine choice. 1s, on the other hand, is
more than 10x the value at the median and is larger than the RTT for 99% of
users. As Patrick says, I think the goal of QUIC is to make the web faster
and would prefer to err on the side of faster.

Cheers,

Ryan

On Wed, Aug 30, 2017 at 6:24 AM, Patrick McManus <[email-masked]>
wrote:

> QUIC has already made the latency over bw trade with the CI by using a
> 1200 byte CI instead of a 3 way handshake. I'd like to think that the CI is
> a small fraction of total quic bandwidth and this is worthwhile.
>
> We've seen applications (especially http applications) push back against
> the historical TCP situation in a number of places even in a TCP context..
> showing that the tradeoff wants to favor latency.
>
>    -
>
>    for years chrome and firefox have both started a new TCP connection
>    when a previous connection attempt has not yet connected after ~300ms. This
>    is to workaround the 3 second OS level timer - which is considered too high
>    of a delay especially when you're otherwise staring at a idle spinner. And
>    yes, that commonly results in 2 completed connections without any TCP level
>    retransmissions - but in the grand scheme of things a couple of packets is
>    a nop but the benefit is significant.
>    -
>
>    chrome, firefox, and edge commonly initiate tcp connections before
>    they have any http data to send on them (perhaps this is done totally
>    speculatively, perhaps it is done by opening N when you only need 1 at the
>    moment.. in anticipation). Mostly this is done for latency purposes - get
>    the tcp and tls handshakes out of the way so they are ready for http data
>    when it happens (some of it can go away when we think 0rtt quic would work
>    instead). Many of these connections close without ever transferring
>    meaningful data - but that's a latency over bandwidth tradeoff (and the
>    bandwidth consumed is small enough in comparison that it doesn't
>    meaningfully impact the real data transfer that goes on).
>    -
>
>    TCP PLT, default on in linux distributions, is another illustration of
>    http applications willing to trade off some wasted retransmissions against
>    the tyranny of large timers.
>
> Also worth nothing that enabling fec extensions is within the wg charter
> (although doing them is not) - and fec is the ultimate in latency over
> bandwidth tradeoff but much harder to get right than the redundant control
> traffic we're talking about here.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/752#issuecomment-325988912>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ASp6yveduPeRDwobG7mEAcHI2pexNhG_ks5sdWKSgaJpZM4PFcXh>
> .
>

-- 
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/752#issuecomment-325998995

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Aug 2017 07:06:34 -0700

Well, all I can say that people complain that my test server sends them multiple SHs and I tell them it's because of the 100ms initial value...

-- 
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/752#issuecomment-326001197

---

From: Christian Huitema <[email-masked]>
Date: Wed, 30 Aug 2017 07:48:28 -0700

On the server side, it is pretty reasonable to do some smart configuration. Also, you could use a repeat of the Client Initial as a retransmission trigger for the SH.

-- 
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/752#issuecomment-326014498

---

From: Christian Huitema <[email-masked]>
Date: Wed, 30 Aug 2017 14:59:43 +0000 (UTC)

>From the table, 150 or 200 would be OK -- no retransmit in 90% of the cases.

There is another way to view this. Currently, the spec specifies a
series of retransmissions with exponential increase of the RTT: T, 2*T,
4*T, 8*T, give up after 16*T. For T at 1 sec, that means retries can
take up to 30 seconds.  That's way too long for many applications. For
100 ms, that's 3 seconds, which is OK-ish but still high. Of course, we
have to cover the 99.5% case above.

-- 
Christian Huitema

-- 
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/752#issuecomment-326018075

---

From: Christian Huitema <[email-masked]>
Date: Wed, 30 Aug 2017 19:26:04 +0000 (UTC)

Of course, if we had synchronized time, we could put a time stamp in the CH, and the server would have an idea of the appropriate timeout for the SH.

-- 
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/752#issuecomment-326093661