Re: [quicwg/base-drafts] Description of the use of Preferred Address is unclear (#3353)

[Kazuho Oku <[e-mail]>]

@ianswett Thank you for your comments.

> I can imagine cases when the CID should be based on the path, so I'm less clear on the correct behavior for the second point. By definition, if the CID provided in the transport param has been retired it should not be used to initiate path validation. But I'm unclear if the preferred behavior is don't migrate if you haven't already initiated migration or to use one of the newer CIDs.

First of all, let me state that we do not need to forbid such a design.

However, in a design that expects CIDs to be specific to the server address being used, a server cannot issue a new CID until the migration to the preferred address completes. This is because if a server sends a NCID frame from the original server address before the client completes migration to the preferred address, the server cannot tell if the client would use that issued CID on the original path (this happen when the client fails to migrate to the preferred address), or if it uses that CID on the migrated path.

Therefore, this issue does not have any effect on such a design.

The question at stake is the client behavior we want to recommend, when the server sends a new CID (or retires CIDs) before migration to the preferred address completes.

My view is that TP.preferred_address is a mechanism of specifying an alternative IP address, that "happens" to also carry a new CID, so that the client can always have an unused CID in hand when it initiates migration to the preferred address.

It is actually simple to implement in such way. What you would do is this:
* When receiving TP.preferred_address, store preferred_address.CID exactly the same way as you would do when receiving an NCID frame, and separately store preferred_address.IP_address.
* When handshake is confirmed, if preferred_address.IP_address is stored, initiate a migration to that address, using a CID from a bucket that holds the unused CIDs.

As stated above, such a design would work perfectly fine with servers issuing CIDs specific to server addresses, because a client would have only one unused CID to pick from when talking with such a server. 

The design is also simpler than having special case code that associates preferred_address.IP_address and preferred_address.CID, and handles retirement cleanly.

-- 
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/3353#issuecomment-575396028