CDN Node Selection Enhancement using Anycast and QUIC

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 10 May 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

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:¶

1. DNS-based redirection: Resolves a hostname to the IP address of a topologically "close" server, typically based on the client's DNS resolver location.¶
2. 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.¶

4. Best Effort (BE) Mode

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

1. Each CDN Node is configured with an IPv4/v6 anycast address.¶

2. 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.¶
3. 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.¶
4. 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.¶

5. Traffic Engineering (TE) Mode

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

6. Security Considerations

TBD.¶

7. IANA Considerations

TBD.¶

Authors' Addresses