Re: [quicwg/base-drafts] Address change and consent to send (#161)

[Martin Thomson <[e-mail]>]

Based on the discussion at the interim, I think that we have a different model in mind now:

If there is a path change, reset the congestion controller.  Absent other information, assume that any change in remote address is indicative of a path change.  You might consider a port-only change to be indicative of hitting the same path.  I don't think that this is a universally safe assumption, because it assumes a great deal about what exists on the other side of the NAT, but we might simply rely on the congestion controller being properly responsive to deal with cases where it genuinely isn't a new path.

If there is a change in the remote address, make sure to obtain proof that the other endpoint can receive your packets at their new address.  Until this is successful, reduce the number of packets you are willing to send on that path to *\<some low rate that might be incidentally related to the initial congestion window\>*.  If this validation fails, terminate the connection.

For the purposes of validation, we will define a new frame that has a randomized payload.  An endpoint would be required to send a copy of that payload back in another frame.  An endpoint can initiate this validation process at any time and for any reason (though it might have to deal with the resulting ENHANCE_YOUR_CALM if it sends it too much).

Note that I said to terminate the connection on this last bit because if validation of the path fails, either you have such a terrible loss issue that you don't want to be using the path, or the other side is spoofing this new source address.

-- 
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/issues/161#issuecomment-307387364