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

[hardie <[e-mail]>]

On Tue, May 23, 2017 at 6:05 PM, Martin Thomson <[e-mail]>
wrote:

> If the PONG doesn't come back, I would say that the path is unusable.
>
> Agreed.

> I can see the case for restoration in the case of a port-only change, on
> the assumption that the path between the remote endpoint and the NAT is
> unlikely to change significantly in terms of characteristics. But an IP
> change could be onto a path with substantially different characteristics.
>
> Here's my proposal:
>
> If the IP address or port of a peer changes, reset the congestion window
> and initiate <insert path validation method here>. Once the validation
> completes, if the IP address of the peer did not change, the congestion
> window MAY be increased to the value it had prior to migration. If the path
> validation method fails completely after <some time>, mark the path as
> unusable, which might cause the connection to fail.
>

So, there are two types of path changes which could happen here.  One is a
change in origin of the path, and an IP change would typically signal that
by being in a different address range.  So you'd have rough heuristics that
said if the new IP is in the same /N that it should be treated as likely
using the same path but that if it is in a substantially different CIDR
block it is likely using a different path.   The other change is one in
which some path elements are using functions like ECMP to share load across
links.  In those cases, a shift in port may also result in a shift in path
because the source port is used in the load sharing function.  While those
functions are generally aimed at keeping the load (and thus congestion) on
the relevant links in balance, there is no way to guarantee that they are.

As a result, what we do here depends a lot on what we're trying to
optimize.  If we want to minimize the lost of congestion control state, I
think we end up with something like:

If the source IP address or port of a peer changes, reset the congestion
window and initiate path validation.  If the path validation method fails
after <some time>, mark the path as unusable.  If the path validation
completes, the congestion window MAY be increased to the value it had prior
to migration; this increase should occur only when it is likely that the
change in IP address or port did result in a path change.  A change in both
port and IP should always be taken as evidence of a path change.

If we are trying to minimize the chance that a congestion window gets
re-opened inappropriately, I think we get something like this:

If the source IP address or port of a peer changes, reset the congestion
window and initiate path validation.  If the path validation method fails
after <some time>, mark the path as unusable.  If the path validation
completes, the congestion window MAY be increased to the value it had prior
to migration if only the port has changed and there is no other evidence in
a change in path.

> Question: do we have to consider the possibility that the prior congestion
> window might decay due to inactivity and account for that here, or is it
> better to continue to run the old controller, feed all the new signals into
> it and switch it in?
>
In the latter case, you mean that you'd feed the signals into both the new
controller created on IP/port change and the controller that existed before
the change, swapping the latter in when the path validation succeeded?

Ted


> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/161#issuecomment-303585687>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5PFhqfaLL3ombwr3D2POfQMiiqyNks5r84JfgaJpZM4LlHwL>
> .
>


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