Subject: [quicwg/base-drafts] Justify retransmitting handshake packets so slowly (#344)

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Feb 2017 19:24:16 -0800

A lost handshake packet is retransmitted after 400ms (assuming that you don't have prior knowledge of the RTT, if you do then it is 2xRTT).  I realize that this is probably shorter than in TCP, but it's still a damned long time to wait.

We are far more aggressive in this in WebRTC with DTLS.  For example, NSS retransmits three times before QUIC even sends its first: at 50ms, 150ms, and 350ms.  We haven't seen much evidence that this is bring the Internet to its knees.  It's certainly good for latency to retransmit more aggressively.  Separately, we also send ICE probes much faster, without the back-off, though those are typically much smaller.

That said, if retransmitting at this pace is somehow doing damage to something, it would be good to understand why this is the case.  We're definitely interested in avoiding an inadvertent damage that we're doing and changing the above numbers could happen pretty quickly with proper justification.

-- 
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/344

---

From: Patrick McManus <[email-masked]>
Date: Fri, 24 Feb 2017 05:31:26 -0800

assuming no loss, what is the fraction of duplicated handshake packets
you're willing to tolerate? A bunch of people have rtt distributions from
the real world. I certainly think ~0% is an unreasonable position.

Myself - I'm willing to tolerate quite a bit (10%?).

Firefox (and iirc chrome) does something similar (and uglier) with TCP @
~250ms without melting the Internet.

On Thu, Feb 23, 2017 at 10:24 PM, Martin Thomson <[email-masked]>
wrote:

> A lost handshake packet is retransmitted after 400ms (assuming that you
> don't have prior knowledge of the RTT, if you do then it is 2xRTT). I
> realize that this is probably shorter than in TCP, but it's still a damned
> long time to wait.
>
> We are far more aggressive in this in WebRTC with DTLS. For example, NSS
> retransmits three times before QUIC even sends its first: at 50ms, 150ms,
> and 350ms. We haven't seen much evidence that this is bring the Internet to
> its knees. It's certainly good for latency to retransmit more aggressively.
> Separately, we also send ICE probes much faster, without the back-off,
> though those are typically much smaller.
>
> That said, if retransmitting at this pace is somehow doing damage to
> something, it would be good to understand why this is the case. We're
> definitely interested in avoiding an inadvertent damage that we're doing
> and changing the above numbers could happen pretty quickly with proper
> justification.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/344>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAP5s4hFu00TjzZbGTWVWgVWi7SrvGuzks5rfk1fgaJpZM4MKyIQ>
> .
>

-- 
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/344#issuecomment-282291555

---

From: ianswett <[email-masked]>
Date: Fri, 24 Feb 2017 05:49:41 -0800

First, I believe the recovery draft is in error, because I meant to recommend a kDefaultInitialRtt of 100ms, which is what Chrome uses, not 200ms.  I also wrote up a slightly more conservative version than the current Chrome default.  

GQUIC currently defaults to 100ms, 10ms, and 1.5x backoff initially, followed by 2x.  I'm testing a more conservative approach which uses 100ms, 25ms and 2x initial backoff, which is what I was intending to recommend.  

But either way, this is definitely more aggressive than TCP, and worth having a discussion about.  I'm not aware of any catastrophic problems, as long as everything uses exponential backoff.

-- 
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/344#issuecomment-282295339

---

From: ianswett <[email-masked]>
Date: Fri, 24 Feb 2017 08:57:49 -0800

In regards to typical rates of spurious retransmissions, hopefully I'll have some data from my two experiments in the near future which will give you an idea of the difference between 150ms and 200ms and 10ms min vs 25ms min.

I believe the default settings in Chrome today result retransmit rate much higher than the 10% number you(and I) might hope for.

-- 
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/344#issuecomment-282343745

---

From: Patrick McManus <[email-masked]>
Date: Sat, 25 Feb 2017 08:32:15 -0800

On Fri, Feb 24, 2017 at 11:57 AM, ianswett <[email-masked]> wrote:

> I believe the default settings in Chrome today result retransmit rate much
> higher than the 10% number you(and I) might hope for.

at 100 I would expect it would be a lot more.. but that's not necessarily a
determining problem

-- 
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/344#issuecomment-282494961