CDN Node Selection Enhancement using Anycast and QUIC

With the proliferation of latency-sensitive and resource-intensive applications, the performance of application servers has become a decisive factor in user engagement and loyalty. CDNs enhance user experience by caching content closer to end-users, thereby reducing latency. The efficiency of a CDN system heavily relies on its ability to select an optimal server node for each client request. Current prevalent node selection mechanisms include:

DNS-based redirection: Resolves a hostname to the IP address of a topologically "close" server, typically based on the client's DNS resolver location.
Anycast routing: A single IP address is assigned to multiple servers. Network routing protocols direct the client's packets to the server that is "closest" in terms of network topology.

These methods, while effective at reducing network latency, generally fail to account for the real-time load on CDN servers or the specific needs of different applications (e.g., compute-intensive vs. bandwidth-intensive). This document specifies a solution that integrates BGP-controlled anycast with advanced features of the QUIC protocol. It enables load-aware route advertisement and provides a standardized way for clients to be redirected to more suitable CDN nodes without terminating their session, leveraging QUIC's connection migration feature.

DNS-based and anycast-based CDN selection schemes primarily optimize for network distance. This document aims to address these issues by creating a more dynamic, load-aware, and application-aware selection mechanism that minimizes service disruption. Existing CDN node selection solutions have the following limitations: DNS-based Redirection and Basic Anycast: Select nodes based on network distance (not server load), leading to load imbalance; Cannot differentiate service types (e.g., low-latency vs. high-bandwidth), resulting in suboptimal service quality; Poor real-time performance and scalability; Route reconfiguration often causes connection interruptions. Service-specific Optimization: Typically non-standard (e.g., video-only protocols), leading to poor compatibility and universality across different services.

This document proposes a distributed dynamic CDN node selection method based on IPv4/v6 Anycast and QUIC. The method considers server load (CPU utilization, remaining computing power), service requirements (high bandwidth, low latency, high computing power), and supports seamless scaling. Key network elements include: CDN Client: Initiates service requests via IPv4/v6 Anycast and QUIC, processes responses, and supports QUIC connection migration. CDN Server: Configured with IPv4/v6 Anycast addresses; advertises/withdraws Anycast routes via BGP based on load; receives and responds to QUIC requests; caches resources from origin servers. The solution supports two working modes: BE (Best Effort) and TE (Traffic Engineering).

In BE mode, the system provides basic load-aware routing and resilience.

Each CDN Node is configured with an IPv4/v6 anycast address.
The CDN Node dynamically manages the BGP advertisement of its anycast address based on its status. For example:
- If the CPU load is below a threshold (e.g., 80%) and the link to its gateway router is not congested (e.g., RTT <= 1.5 * baseline RTT), the node advertises a route for the anycast address via BGP.
- If the CPU load exceeds the threshold or the link becomes congested, the node withdraws the BGP route.
A client sends its initial QUIC packets to the anycast address. BGP directs these packets to the topologically nearest CDN Node that is currently advertising the route.
If the serving CDN Node becomes unavailable (e.g., because it withdraws its BGP route due to overload), the client's subsequent packets will be routed to the next-nearest available node. The client detects this path change and uses QUIC's connection migration feature RFC9000 to seamlessly continue the session with the new node without re-establishing the connection.

TE mode extends BE mode by allowing for more granular, application-aware node selection. In TE mode, CDN Nodes are assumed to have knowledge of their ranking relative to other nodes within a specific domain (e.g., all nodes serving a particular region). This ranking is based on three key metrics:

Compute Power (Kn): A rank indicating the node's available computing capacity (e.g., based on FLOPS). A lower Kn value might indicate higher available compute.
Latency (Dn): A rank based on the baseline network latency from the node to its gateway, indicating its proximity to the network edge. A lower Dn value indicates lower latency.
Bandwidth (Bn): A rank representing the node's available network bandwidth. A lower Bn value might indicate higher available bandwidth.

The specific mechanism by which nodes discover each other and determine these ranks (e.g., via a centralized controller or a distributed discovery protocol) is outside the scope of this document.

TBD.