Word-smithed version of Ted's resolution to #3842 from the mailing list #3945
Conversation
|
This LGTM and would address my concern. |
Co-authored-by: ianswett <ianswett@users.noreply.github.com>
Co-authored-by: Jana Iyengar <jri.ietf@gmail.com>
ianswett
added
-transport
design
draft-ietf-quic-transport.md
Outdated
| congestion controller and the RTT estimator are expected to adapt to the new | ||
| path. Generally, implementations are advised to be cautious when using previous | ||
| values on a new path. | ||
| unless the only change is the other endpoint's port number. Because |
There was a problem hiding this comment.
On the mailing list, I asked whether I should add "and the connection ID did not change" to the end of this sentence. Opinions?
There was a problem hiding this comment.
I think not. Implementations that know they're likely to have a NAT rebinding (i.e. after quiescence) are advised to change the CID as well. That doesn't make it less a NAT rebinding.
There was a problem hiding this comment.
The point is that if the CID changed, it was an active migration attempt, which indicates that the peer at least attempted to switch paths. So in those cases resetting the state might make more sense.
There was a problem hiding this comment.
Yeah, I agree that it's consistent with the idea that the peer likely changed its attachment point. I don't think this makes a difference in practice, but it seems consistent with our principles here.
It does make it a bit more work to check, but it's not that hard.
There was a problem hiding this comment.
Correctly predicting a NAT rebind isn't an "attempt" to switch paths. It's using the same path, but making a guess about what might have happened.
If you're not going to reset the congestion controller when the port changes without the peer realizing it, and you're not going to reset the congestion controller if the peer guesses they're about to get rebound but doesn't, then I don't think it makes sense to reset it if they guess and are right.
There was a problem hiding this comment.
We encourage changing the CID and port to "force" a NAT rebinding if you've been idle (Section 9.5) in order to reduce linkability. In the same breath, we note that this might reset congestion controller state, so be careful about changing port too often. A conservative implementation of that guidance might change CID but not port, letting NAT rebindings happen if they happen.
There was a problem hiding this comment.
I don't see how the text in Section 9.5 conflicts with the proposed change?
There was a problem hiding this comment.
Whether an endpoint passively experiences or deliberately forces a NAT rebind is indistinguishable at the server side. Changing CID tells you nothing more than that they wanted to reduce their linkability if they got rebound. A change in CID doesn't imply a path change; a change in endpoint address is the only reliable guide on that.
We're saying that you SHOULD reset unless there's a change that's broader than the port, because a port-only change is very likely to be the same path. A CID change is even less likely to indicate a path change. Therefore, it should not be a cause for resetting the congestion controller.
There was a problem hiding this comment.
@MikeBishop: I see your point. The concern @larseggert was trying to address was that in some carrier-grade NATs, it is possible that what appears as a port change might actually be a path change on the private side of the CGNAT, but your point is that CID change cannot be assumed to be a good proxy for path change. At a minimum, we don't have experience with this yet, so we can't assume it.
I don't have a strong opinion one way or the other here. In practice, I completely expect people to treat port changes as same path. Given @MikeBishop's point about CID changes also not reflecting a path change, I would suggest leaving the PR as it is.
There was a problem hiding this comment.
@MikeBishop is there something left to resolve here?
draft-ietf-quic-transport.md
Outdated
| congestion controller and the RTT estimator are expected to adapt to the new | ||
| path. Generally, implementations are advised to be cautious when using previous | ||
| values on a new path. | ||
| unless the only change is the other endpoint's port number. Because |
There was a problem hiding this comment.
Yeah, I agree that it's consistent with the idea that the peer likely changed its attachment point. I don't think this makes a difference in practice, but it seems consistent with our principles here.
It does make it a bit more work to check, but it's not that hard.
Co-authored-by: Jana Iyengar <jri.ietf@gmail.com>
Co-authored-by: Jana Iyengar <jri.ietf@gmail.com>
…fts into 3842-list-resolution
|
I think this is good to go. |
Closes #3842.