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

[Mike Bishop <[e-mail]>]

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

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.

-- 
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_r470839962