PATH_CHALLENGE timer period

[gorryfair]

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.

[ianswett]

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

[ianswett]

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