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

From: janaiyengar <[email-masked]>
Date: Fri, 08 Sep 2017 12:27:35 -0700

Finally getting to this. Note that the initial RTT only matters insofar as retransmissions are concerned. The handshake RTO is 2 x initialRTT, which means retransmissions should happen after 200ms, which is good enough for 90% of the cases.

Separately, on constants: the IETF has always been reluctant to change TCP's constants despite the fact that implementations have changed them a long time ago. Consider the min RTO, which is still recommended by RFC 6298 to be 1 second, is not used in practice. The minimum RTO in Linux is ~200 ms.

I agree with @mcmanus: I would put latency over bandwidth, or at least provide a knob to allow QUIC implementations to put latency over bandwidth. In this case, I would argue that a few extra retransmissions are really not a major cost, but waiting for a long time when you have just one packet outstanding in the network is a massive cost that browsers and server have repeatedly shown to be worth reducing.

It's all about latency. IMO a few extra retransmissions don't matter.

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

---

From: ianswett <[email-masked]>
Date: Fri, 15 Sep 2017 19:26:32 +0000 (UTC)

Yes, the intent is the first CHLO retransmission occurs at 200ms, which seems quite reasonable to me.  We could change it to 300ms by making the default 150ms, but I don't see a compelling reason to do that.

1s is certainly not what I'd recommend.

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