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

Gorry Fairhurst <notifications@github.com> Thu, 18 July 2019 13:32 UTC

Date: Thu, 18 Jul 2019 06:32:38 -0700
From: Gorry Fairhurst <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6W4VNUTSZVGXEA3P53HWTXNEVBNHHBYABG4Q@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2910@github.com>
Subject: [quicwg/base-drafts] PATH_CHALLENGE timer period (#2910)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d3074f6ab9d0_1fb33fb2028cd964556141"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/UJo5x15SnPcKbVOJgQJX1an03-g>

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

[quicwg/base-drafts] PATH_CHALLENGE timer period … Gorry Fairhurst
Re: [quicwg/base-drafts] PATH_CHALLENGE timer per… ianswett
Re: [quicwg/base-drafts] PATH_CHALLENGE timer per… ianswett
Re: [quicwg/base-drafts] PATH_CHALLENGE timer per… ianswett