How to handle preferred address migration?

[huitema]

I am wondering what is supposed to happen if the server sends a "preferred address" parameter. My understanding of the draft is that all packets produced by the client are sent to the IP address and port specified in the CONNECT-UDP request. It follows that if the client wants to heed the "preferred address" parameter, it should set up a new proxy connection for that. Is that a correct understanding? Should we explain that in the draft?

[tfpauly]

@huitema do you mean if the proxy server sends a preferred address parameter, or the target server sends a preferred address parameter?

If the proxy sends that, then the client should move to use that for all of its proxying, and the flows just go there. The "client-to-proxy 5-tuple" moves.

If the target sends that, then it's more about moving the "proxy-to-target 5-tuple". The proxy wouldn't know what new preferred address is, so the client would need signal the proxy.

This could either be done as an entirely new connect-udp proxy request, or as a new capsule to the proxy.

[tfpauly]

See also #86

[huitema]

Preferred address migration is pretty much the only example of migrating to a different server address. There is an interesting interaction with the multipath extension, which suggests that preferred address migration be treated as a migration event.

I think that the only way to signal a server address is by sending another CONNECT_UDP command, with a different "path" value. Maybe we should explain that in the draft.

[gloinul]

So shouldn't the server preferred address for the QUIC connection and its migration happen prior to processing the CONNECT_UDP request? I only see it working to process it early if the one responding have full control and can control both the preferred address and its external side address(es). As a server if you are migrating you need to have that in mind before you process quic aware proxying capsules as they would need to apply to both original and migrated address if you process them prior to the migration have happened.

[ihlar]

I think that the only way to signal a server address is by sending another CONNECT_UDP command, with a different "path" value. Maybe we should explain that in the draft.

Agree, when migrating to new target server address the most straight forward solution would be to simply make a new connect-request. I don't think we need to do any protocol changes for this case, e.g., defining new capsules, but describing the scenario is a good idea.

[DavidSchinazi]

Using a different CONNECT-UDP request is definitely the simplest option. The issue is that the second CONNECT-UDP request could land on a different proxy from the first (especially in the presence of intermediaries), so you could end up reaching the preferred address from a proxy that can't reach it. Not sure if that's something worth worrying about though. Same for the performance cost of bringing up a whole new CONNECT-UDP context. I suspect using a second CONNECT-UDP request is good enough for now, and if these problems do happen in practice, then we'll have a reason to solve them.

[huitema]

Yes, I thought about that extra complexity of multiple paths either from the client or from the proxy. The client can certainly connect to several proxies, and have different paths routed through different proxies -- that would get you some independent end-to-end paths. But in the case of the "multihomed proxy", the client currently does not control the source IP of the packets sent to the target. We would need a mechanism for the proxy to provide a list of available addresses, and an extension to the "path" parameter to indicate the preferred source address.

[huitema]

To answer the question about timing from @gloinul : it is probably best to not tie the internal state of the QUIC path and the state of the QUIC-Connect context. The timing should be something like:

• QUIC connection is requested to open a new path with specific target address,
• new UDP Connect is requested, specifying new address.
• UDP connect is accepted
• Packet containing Path Challenge is sent to the proxy using the new context
• Proxy forwards the Path Challenge to the target
• Target replies with Path Response
• Target packet recognizes the source IP and source port of the path response, associate the response with the UDP Connect context.
• Proxy send the Path Response to the client per UDP context.
• Client sets target context for the selected CID.

The client does not really know which CID the proxy will pick for the response, so it cannot create a context before receiving the path response, so the proxy shall be able to find the Connect UDP context based on addresses.

[gloinul]

Yes, one will have to run the path challenge at least in tunneled mode. After that one can optimize the forwarding when the CIDs for the E2E path is properly known.

[tfpauly]

At 120 we said that we should just do a new connect-udp request, and have some text that describes the case. The one case that could be suboptimal is that the client might not know which address was used originally, so if the preferred address is the same as the original, the client might unnecessarily make a new proxy connection (unless if gets a proxy-status header back to tell what the next hop is). This can be described.