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

[Ryan Hamilton <[e-mail]>]

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 <[e-mail]>
wrote:

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