Questions about QUIC and Anycast

[William Herrin <[e-mail]>]

Hi folks,

I've been reading draft-ietf-quic-transport-16 and seek some
clarification about how QUIC is intended to work with Anycast routing.
For anyone unfamiliar with Anycast routing, that's where multiple
servers located around the world are all configured with the same IP
address. The client's packet routes to the "nearest" of those servers
as selected by the layer-3 routing protocols.


>From what I've read there are two ways to robustly support anycast
with QUIC: A. The responding server can issue a unicast preferred
address. The client switches to the preferred address. B. The
responding server can pick a connection ID according to a
non-overlapping pattern for all servers within the anycast cluster.
The pattern can be used to route each client packet to the correct
server.

Question 1: Did I miss anything? Do the QUIC authors envision any
additional ways of supporting Anycast-routed servers?


Section 9.6 of the draft describes the server issuing a preferred
address. So once anycast finds the best server, use of the server's
unicast address lets the client stick with it. However, as I read it
the client and server must complete TLS negotiation before the client
can attempt a connection migration.

Question 2: Which packet contains the server preferred address? Is
this in the first response packet to the client? Can the client start
trying to use the preferred address with its second packet or does it
have to wait? Is it allowed to continue using the non-preferred
address and, if so, will it fail over to attempting the preferred
address if its communication fails in some way (no response or
rejection from the server at the non-preferred address)?

I ask this because Anycast routing has a packet spread case in which
per-packet load balancing, ECMP anomalies and other network funkiness
cause the client's second packet to reach a different server in the
cluster than the first. Both behaviors have been observed in the wild.
If the client can't reliably switch to the preferred address on packet
#2, the preferred address will fail to solve the Anycast use case.


Section 5 describes connection IDs. As I read it, the responding
server selects one or more integers whose presence in the client's
packet along with the client's selected connection IDs associate the
packet with an ongoing connection. It's possible to constrain the
server selection of those integers such that a simple algorithm
applied to the server's connection ID (such as an AND mask) uniquely
identifies which server in an Anycast cluster handles the associated
connection. A load balancer fronting the cluster or a packet rerouting
process in the Anycast QUIC implementation could then move the packet
to the server capable of handling it.

Question 3: What picks the connection ID? Does the API allow the
application software to influence the selection of connection ID in
any way?


Question 4: Is the connection ID inside or outside the encrypted
portion of the packet?


Question 5: Fragmentation needed / Packet Too Big messages originate
from an intermediate router that often has.a different return path
than the route taken by packets from the endpoint. How is QUIC
intended to deal with packet too big messages which arrive at a
different node in the Anycast cluster than the one which sent the
overlarge packet?


Thanks,
Bill Herrin


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