Original text:
changes, the initial RTT SHOULD be set to 500ms, resulting in a 1 second initial handshake timeout as recommended in RFC6298.  When a crypto packet is sent, the sender MUST set a timer for twice the smoothed RTT.  This timer MUST be updated when a new crypto packet is sent and when an acknowledgement is received which computes

Reviewer comments:
Using PATHCHALLENGE/PATHRESPONSE I'm fairly happy with the text, but not that happy with the location. Especially after the recently filed issues(ie: ) on resetting the congestion controller on path changes, I think we may need a section in recovery on that.
Do we really want to keep the requirement to respond with a PATH_RESPONSE immediately? This doesn't talk about paths. Now, we might infer from this that the RTT to a peer isn't likely to dramatically change when paths change, but we'd want to be saying that directly. How does this sit with the change in ?
On 2.: if you roam from 5G to 3G you could see significant latency spikes. Phasing out 3G networks and keeping 2G could move traffic to 2G EDGE in areas of thin coverage. Traffic could also move to narrow band IoT (if it is possible to run QUIC on these at all) with MUCH higher latency. Endpoints could choose stay on narrow band most of the time to save battery and perhaps online costs, but use 5G when a device wakes up for real (I could see a use case for that). Though of course might be served with separate connections for such extreme transitions.
I think this is OK as long as we limit how many path responses we send immediately? Realistically, it's not that different from a generate_204, but it's something to be aware of. I think we need to add a whole section on paths and connection migration in recovery. See I can do that in this PR if people want? decreases the value of this, since you may only see one half of the path. It might still be better than nothing? Initial RTT doesn't need to be correct, but getting it within a factor of 2 is helpful.
NAME I don't think you meant 2367
Thanks David, fixed.
I'm split on this. While I understand the urge to optimize here, I'm not sure that documenting it here is necessary. Saying that an endpoint MAY use this signal gives permission, but does so without noting the potential issues. At a minimum, you would need to talk about the problems that are lurking ... especially in light of , as I've noted in . Which leads me to wondering if it's really worth documenting this here without more experimentation and data.
I'm a fan of forbidding it's use as an actual RTT measurement, which would be one reason to say something?
I'd prefer that it's NOT forbidden. I'm fine with waiting for experimentation.
I changed this to SHOULD NOT from MUST NOT to allow some experimentation.
Section 9.4 contains a mixture of transport (handling migration, setup, etc) and congestion control functions (choice of path parameters - RTO, window, etc). The abstract suggests that these are a part of QUIC Recovery ID, which seems correct to me. So, I would like to discuss if these are intentionally a part of the transport spec, rather than the Loss Detection & Congestion Control Spec.? Specifically, para 1,2 : "... SHOULD NOT contribute to congestion control or RTT estimation for the new path." and "... SHOULD immediately reset ...." - Where the ID could note whatever transport implementors need to be aware of, but point normatively to the QUIC Recovery ID for RFC2119 language. Para 3: "An endpoint MUST NOT return to the send rate..." seems a reasonable thing to note, but also, I think, should point to QUIC Recovery ID.
Discussed in London: NAME to work with NAME to propose an editorial PR
The target is to fix this issue with the same PR as
Discussed today with editors and we believe that these issues have been rectified in the numerous edits that section has received since this issue was opened.
Should the recovery draft explain how to gather RTT samples during connection migration using PATHCHALLENGE and PATHRESPONSE? This is explained in: URL
Is there any expectation that the response is sent immediately?
Section 8.4:
If PR lands, we'd need to restrict this to cases when the PATHRESPONSE arrived on the same path the PATHCHALLENGE was sent on.
NAME don't we already have text about that?
NAME removes that text. NAME is right, we'll need to caveat this at a minimum. I think it gets a bit tricky to use the PATH_CHALLENGE/RESPONSE for RTT if the RESPONSE can arrive on any path. The endpoint does not know what path will be used for data/acks, and it would have to assume that the path for CHALLENGE/RESPONSE will be the one used for data/acks, if it is to set its RTT estimate. Perhaps we could say that an endpoint can use the CHALLENGE/RESPONSE RTT as a hint. This will need some more thought.
How about "MAY use the delay between sending a PATHCHALLENGE and receiving a PATHRESPONSE to seed initial_rtt for a new path, but MUST not be considered an RTT sample."?
Discussed with Ian in London: I'm okay with just using the PATHCHALLENGE/PATHRESPONSE RTT as the initial RTT.
Thanks NAME can you review the outstanding PR?

Revised text:
changes, the initial RTT SHOULD be set to 500ms, resulting in a 1 second initial handshake timeout as recommended in RFC6298. <ins> A connection MAY use the delay between sending a PATH_CHALLENGE and receiving a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT be considered an RTT sample. </ins> When a crypto packet is sent, the sender MUST set a timer for twice the smoothed RTT.  This timer MUST be updated when a new crypto packet is sent and when an acknowledgement is received which computes