Preferred Address needs clarifications

[MikeBishop]

Two things need to be clarified around SPA:

• The CID is not path-specific; it's there to ensure that the client has a second CID before the handshake completes. If the client opts not to migrate, the client can use that CID on the
• The IP addresses in the SPA are only for use in the transition post-handshake; the client should not cache the IP addresses for any other use.

[erickinnear]

(Just filling in the text here)

the client can use that CID on the

on the original address from the server, which is the existing connection, not-migrated.

+1 to the second point

[notonymous]

if the client opts not to migrate ...

Section 9.6.1 says "Once the handshake is finished, the client SHOULD select one of the two server's preferred addresses ..."

If the server is telling the client to migrate to a SPA, should this be changed to "the client MUST select one of the two server's preferred addresses ..."?

If the text remains a SHOULD, and the client stays on the old server address, what can the server do if it is only willing to continue with the new connection on the SPA? The server could close the initial connection using the old server address but there isn't a transport error code (e.g. MIGRATION_ERROR) that would explicitly tell the client why the connection is being closed.

[martinthomson]

The "SHOULD" is intentional. A server cannot rely on clients moving.

[notonymous]

Then perhaps a cautionary note such as "If the client opts not to migrate to a preferred address, the server may [lower case] decide to close the connection (e.g. SERVER_BUSY)".

[MikeBishop]

If the server isn't willing at all to handle connections on its published IP address, then (naively) it shouldn't accept connections on that IP address and should publish the other one instead. The scenario this targets is that it's somehow better for the client to use a different address, but that other address can't necessarily be known in advance.

[notonymous]

If the server isn't willing at all to handle connections on its published IP address, then (naively) it shouldn't accept connections on that IP address and should publish the other one instead.

I thought the use case in section 9.6 was pretty clear -- "This is particularly useful when clients initially connect to an address shared by multiple servers but [the server] would prefer to use a unicast address to ensure connection stability".

Migrating to a unicast address avoids having to perform connection-based routing through a load balancer.