Re: [quicwg/base-drafts] Word-smithed version of Ted's resolution to #3842 from the mailing list (#3945)

[Jana Iyengar <[e-mail]>]

@janaiyengar commented on this pull request.



>  immediately reset the congestion controller and round-trip time estimator for
 the new path to initial values (see Appendices A.3 and B.3 in {{QUIC-RECOVERY}})
-unless it has knowledge that a previous send rate or round-trip time estimate is
-valid for the new path.  For instance, an endpoint might infer that a change in
-only the client's port number is indicative of a NAT rebinding, meaning that the
-new path is likely to have similar bandwidth and round-trip time. However, this
-determination will be imperfect.  If the determination is incorrect, the
-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

@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.

-- 
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/pull/3945#discussion_r472488858