Re: Questions about QUIC and Anycast

[William Herrin <[e-mail]>]

Thanks Martin, Igor:

I appreciate your insight. This leads me to a couple of additional questions.

On Mon, Dec 10, 2018 at 4:41 PM Martin Thomson <[e-mail]> wrote:
> On Tue, Dec 11, 2018 at 11:18 AM William Herrin <[e-mail]> wrote:
> > Question 3: What picks the connection ID? Does the API allow the
> > application software to influence the selection of connection ID in
> > any way?
>
> The server picks connection IDs that the client puts in packets.  That
> selection really has to be done in consultation with load balancers or
> the folks managing routing configurations.

How does short header versus long header impact this? Can the server
instruct the client to use the full destination connection ID in both
headers so that the full connection ID is available to a middlebox in
every packet?


> > Question 2: Which packet contains the server preferred address?
>
> In practice, taking some of the less-used exchanges (Retry, Version
> Negotiation, a TLS HelloRetryRequest) out of the picture, the server
> will often include the value in the first flight of packets it sends.
> However, that can be a couple of round trips away from the end of the
> handshake, because the handshake is multiple packets and might need to
> be repaired due to packet loss.

Hmm. I'm curious what the reasoning is here. TLS would have to satisfy
the same cryptography regardless of which address is used, would it
not? Presumably the client could return to the original address upon
failed communication with the preferred address, including a failure
to negotiate TLS. How does requiring the TLS negotiation to complete
before attempting the preferred address end up enhancing security in
the bigger picture?

Does the preferred address have another use case besides load
balancing? The load balancing process could be stateless if it could
rely on the client shifting to the preferred address on packet #2. It
seems to me that making the load balancing process stateless,
especially in the anycasted CDN case, would be a big win if it could
be done securely.

Regards,
Bill Herrin



-- 
William Herrin ................ [e-mail]  [e-mail]
Dirtside Systems ......... Web: <http://www.dirtside.com/>