Change:
The intent here was that either (a) you only ever have a singe CC context and you reset it for each path, or (b) you have a CC context for each path, in which case each context is strongly tied to a path and you don't need to reset anything (except when it's been a while and the previous values may no longer be valid, etc.). We require that everyone does at least (a), while not preventing folks who want to do extra work for a potential performance gain from doing (b). Packets can contribute to the CC/RTT estimation for the old path if it's still around and you're willing to maintain that state, which is why this (mistakenly) was a SHOULD.
This looks good. I'm calling it editorial. However, it changes normative language, so I want an opinion on that from at least NAME or NAME before merging (other opinions are also highly valued).
+1 that we should require this behavior. We know that implementers will try out tricks here if they want to, and there's no enforcement to stop that from happening.
I agree that this seems generally editorial, but either way I think this is ready to go?
This is awkward, because the issue of assumptions about the path appears spread over multiple places. Section 9.4 of draft-ietf-quic-transport : The capacity available on the new path might not be the same as the old path. Packets sent on the old path SHOULD NOT contribute to congestion control or RTT estimation for the new path. GF: That would be fine IF the new path were a separate CC context, which I am not yet clear whether it is, read on: — Section 9.4 of draft-ietf-quic-transport : On confirming a peer's ownership of its new address, an endpoint SHOULD immediately reset the congestion controller and round-trip time estimator for the new path. GF: Why not MUST? - because I think this is a new path, I think it can only be should if something can confirm this is the same set of network-devices and classifiers on the path. I don't know how you would know that, and I don't like the guess. — draft-ietf-quic-transport : For instance, a change in the client's port number is likely indicative of a rebinding in a middlebox and not a complete change in path. GF: So. maybe this is the guess, and I don't believe it! In a world of ECMP and other methods, this needs to be treated as a potential change of path. — Section 9.4 of draft-ietf-quic-transport: While multiple paths might be used during connection migration, a single congestion control context and a single loss recovery context (as described in [QUIC-RECOVERY]) may be adequate. GF: Well it could if the paths WERE known to be identical, but how would an endpoint guarantee that? Section 9.2 of QUIC transport seems to suggest the CC is reset for the new path, which I would agree with, but which part of QUIC recovery says that? — draft-ietf-quic-recovery: For instance, an endpoint might delay switching to a new congestion control context until it is confirmed that an old path is no longer needed (such as the case in Section 9.3.3). GF: This seems underspecified and novel to me. I think it may b quite OK to continue using the old path and the old CC, for a while. Same question: is this implying the two paths share a single CC and is there some real mechanism to detect that they are really the same set of network devices on path?
1) SHOULD NOT -> MUST NOT Suggestion: "New paths have new congestion control contexts, implementations can reset the existing congestion control context." 2) In keeping with the first resolution, it's a new CC, and whether a new CC is created or the existing one is reset is an implementation decision. 3) Instead of saying it's the same path, say that the path parameters(RTT and CC state) are likely to be similar. 4) This is resolved with the resolution to 1, we can decide where the implementation note should live. 5) (In Section 9.4 of transport) This is really "A path can be validated, but not switched to immediately, particularly in the presence of a potential attack. When you switch, you need to use a new(or reset) congestion controller."
For 5, we need to say a bit more about the fact that the attack is that when a sender receives data on a new path causing it to potentially reset its CC state immediately if it switches immediately.
For 1,2,4: I think this was always the intent -- some implementations don't want to have two CC contexts so they can reset it and start with zero assumptions about the new path. Implementations that are okay with having more than one will make a new one and use that on the new path, switching back to the old one if they use the old path and the information is still relevant (i.e. it's been <1 RTT and you decided the new path wasn't actually better -- pick some threshold I don't have a strong preference). 3: Yes, it's not necessarily exactly the same path. An endpoint that wants to put in extra effort in determining which paths are equivalent to make a smarter decision can do so while the default behavior is a complete reset every time (after confirming the migration). This also impacts (5) around some of the attacks. 5: I agree with NAME we should be a bit more explicit about preventing an off-path attacker from being able to cause continuous resets as you go back and forth between paths, that's a good case where you would want to keep CC state around (if you're being told to swap multiple times per-RTT you've got other issues, too, which are mostly addressed but might need some more text, likely in transport).
Discussed in Cupertino. NAME to propose a PR, current belief is that it will be Editorial (classifying as such); if not, we'll reclassify.
We've summarized some discussion for these above, but to go through the resolution plan for concrete changes for each one: The intent here was that either (a) you only ever have a singe CC context and you reset it for each path, or (b) you have a CC context for each path, in which case each context is strongly tied to a path and you don't need to reset anything. We require that everyone does at least (a), while not preventing folks who want to do extra work for a potential performance gain from doing (b). Addressing this in a PR: They can contribute to the CC/RTT estimation for the old path if it's still around and you're willing to maintain that state, which is why this (mistakenly) was a SHOULD. Yes, this should be a MUST, because the CC/RTT for that path has to be reset for a new address, either by making a new one for the new path and keeping the old one around for the old path, or by resetting your single one. This is now a MUST in the current editor's copy. A very good point! This is now: This seems to address the need for caution here. This is intended to say that you aren't required to maintain additional per-path state, it's adequate to reset it for each path. In recovery, the section entitled "Handshakes and New Paths" discusses initial values to use on a new path. In general, recovery seems to be an instance of CC/LR, so if transport instructed you to toss out the old one and make a new one, you'd be using initial values, etc. as specified in recovery. Transport does require that you reset CC/RTT a few paragraphs above (as noted in your previous comment): I don't think we're trying to specify a new mechanism to determine equality of paths across a network. The intent here is to recommend that an endpoint be a little bit cautious about throwing out its state before it knows it's really going to be sticking with the new path.

Discussion:
9.4. The capacity available on the new path might not be the same as the <del> old path.  Packets sent on the old path SHOULD NOT contribute to </del> <ins> old path.  Packets sent on the old path MUST NOT contribute to </ins> congestion control or RTT estimation for the new path. On confirming a peer's ownership of its new address, an endpoint MUST