Subject: [quicwg/base-drafts] PATH_CHALLENGE timer period (#2910)

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

Section 9.4 of draft-ietf-quic-transport:
   An endpoint might set a
   separate timer when a PATH_CHALLENGE is sent, which is cancelled when
   the corresponding PATH_RESPONSE is received.  If the timer fires
   before the PATH_RESPONSE is received, the endpoint might send a new
   PATH_CHALLENGE, and restart the timer for a longer period of time.

GF: Possibly so, but what value has this timeout? 
- To avoid potential congestion collapse, I think this needs to be conservative enough to deal with paths with significant RTT variance, or where there is a change of base RTT. 1 sec, then 3 seconds, and then exponentially backed-off would be expected for TCP SYNs, and I suggest could be appropriate.

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

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 10:22:51 -0700

The suggestion is to move some of this text to recovery(ie: Handshakes and New Paths) and reference that text from transport.

-- 
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/2910#issuecomment-513572229

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 10:25:36 -0700

As Jana pointed out, this specifies a separate timer, which fits fine with the model that there's one timer per path.

-- 
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/2910#issuecomment-513572427