Subject: [quicwg/base-drafts] Preferred Address needs clarifications (#3432)

From: Mike Bishop <[email-masked]>
Date: Thu, 06 Feb 2020 01:26:18 -0800

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.

-- 
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/3432

---

From: Eric Kinnear <[email-masked]>
Date: Thu, 06 Feb 2020 01:49:33 -0800

(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

+1 to the second point

-- 
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/3432#issuecomment-582821465

---

From: notonymous <[email-masked]>
Date: Thu, 06 Feb 2020 09:00:09 -0800

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

-- 
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/3432#issuecomment-583004667

---

From: Martin Thomson <[email-masked]>
Date: Sun, 09 Feb 2020 13:50:14 -0800

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

-- 
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/3432#issuecomment-583897873

---

From: notonymous <[email-masked]>
Date: Sun, 09 Feb 2020 18:18:21 -0800

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)".

-- 
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/3432#issuecomment-583928490

---

From: Mike Bishop <[email-masked]>
Date: Wed, 12 Feb 2020 11:32:47 -0800

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.

-- 
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/3432#issuecomment-585378345

---

From: notonymous <[email-masked]>
Date: Wed, 12 Feb 2020 13:44:48 -0800

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

-- 
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/3432#issuecomment-585433061