Subject: Re: [quicwg/base-drafts] Use a higher seed RTT for new paths (#2789)

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 06 Jul 2019 03:41:52 -0700

I missed this, and the text isn’t correct, but my comment was over-simplified  - and I am on vacation for a week, really sorry. 

So will get back after the vacation.

Gorry 

> On 17 Jun 2019, at 17:16, ianswett <[email-masked]> wrote:
> 
> I reread 6298 and I also can't find the 1.5 text. Can you point out which text you have in mind?
> 
> The goal is not to base the new path's congestion control properties on the previous path, but if there was a PATH_CHALLENGE/RESPONSE before migrating, then it's ok to use that to seed the initial_rtt.
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.

-- 
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/2789#issuecomment-508915973

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 18 Jul 2019 06:00:35 -0700

I get this text. The vacation helped me, but I still struggle to work out the full pathology.

So, can we move forward: What happens if that "unmeasured" timeout period expires,  is the timeout re-initialized to increase it to 3 seconds [RFC6298] [RFC8085]. I think this conservative increase is necessary to avoid congestion collapse when many flows retransmit across a shared bottleneck with restricted capacity.

-- 
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/2789#issuecomment-512804808

---

From: ianswett <[email-masked]>
Date: Fri, 19 Jul 2019 04:11:58 -0700

I believe the relevant text is(?):
" (5.7) If the timer expires awaiting the ACK of a SYN segment and the
         TCP implementation is using an RTO less than 3 seconds, the RTO
         MUST be re-initialized to 3 seconds when data transmission
         begins (i.e., after the three-way handshake completes)."

I believe that's saying the RTO should be set to 3 seconds if any syn timers expired?  Do implementations(ie: Linux, Windows, etc) do that?  If so, that means a single packet loss in the handshake causes the RTO to increase to 3 seconds, but a subsequent data packet loss would not have that effect?

@gorryfair  If you're in Montreal Saturday or Sunday at the Hackathon, maybe we can talk about this more and figure out what to do 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/2789#issuecomment-513190762

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 19 Jul 2019 05:59:15 -0700

Yes, let’s talk Montreal.

I think your comments hold true - and this is about backing off an initial exchange, not about data when there has already been a handshake. In a @normal@ case, you should not see this happen. Talk to you sat (or if not, on sun).

Gorry

> On 19 Jul 2019, at 12:11, ianswett <[email-masked]> wrote:
> 

-- 
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/2789#issuecomment-513219110

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Jul 2019 08:26:28 -0700

Discussed in Montreal; editors to prepare a PR.

-- 
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/2789#issuecomment-514680143