



QUIC Working Group                                                 Z. Li
Internet-Draft                                                     Z. Du
Intended status: Standards Track                            China Mobile
Expires: 10 May 2026                                            W. Cheng
                                                                 J. Wang
                                                                  Centec
                                                         6 November 2025


         CDN Node Selection Enhancement using Anycast and QUIC
               draft-li-cdn-node-selection-enhancement-00

Abstract

   Content Delivery Networks (CDNs) are critical infrastructure for
   improving user experience by serving content from geographically
   proximate servers.  Traditional CDN node selection mechanisms, such
   as DNS-based redirection and BGP-based anycast, primarily rely on
   network proximity and often lack awareness of server load or specific
   application requirements.  This can lead to suboptimal performance
   and inefficient resource utilization.

   This document proposes an enhanced mechanism for dynamic CDN node
   selection that leverages IPv4/v6 anycast, BGP, and the QUIC transport
   protocol.  The proposed solution enables CDN nodes to advertise or
   withdraw their anycast routes based on real-time load and link
   quality.  Furthermore, it defines a mechanism for clients to signal
   their service requirements (e.g., high-compute, low-latency, or high-
   bandwidth) and for servers to redirect clients to more optimal nodes
   using QUIC's connection migration capabilities.  This allows for a
   more intelligent, load-aware, and application-aware CDN node
   selection process.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in .

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



Li, et al.                 Expires 10 May 2026                  [Page 1]

Internet-Draft        CDN Node Selection with QUIC         November 2025


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Best Effort (BE) Mode . . . . . . . . . . . . . . . . . . . .   4
   5.  Traffic Engineering (TE) Mode . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

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.





Li, et al.                 Expires 10 May 2026                  [Page 2]

Internet-Draft        CDN Node Selection with QUIC         November 2025


   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.

2.  Problem Statement

   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:

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

   2.  *Service-specific Optimization*:

       *  Typically non-standard (e.g., video-only protocols), leading
          to poor compatibility and universality across different
          services.







Li, et al.                 Expires 10 May 2026                  [Page 3]

Internet-Draft        CDN Node Selection with QUIC         November 2025


3.  Solution

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

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.




Li, et al.                 Expires 10 May 2026                  [Page 4]

Internet-Draft        CDN Node Selection with QUIC         November 2025


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

   Zhiqiang Li
   China Mobile
   Beijing
   100053
   China
   Email: lizhiqiangyjy@chinamobile.com








Li, et al.                 Expires 10 May 2026                  [Page 5]

Internet-Draft        CDN Node Selection with QUIC         November 2025


   Zongpeng Du
   China Mobile
   Beijing
   100053
   China
   Email: duzongpeng@chinamobile.com


   Wei Cheng
   Centec
   Suzhou
   215000
   China
   Email: chengw@centec.com


   Junjie Wang
   Centec
   Suzhou
   21500
   China
   Email: wangjj@centec.com





























Li, et al.                 Expires 10 May 2026                  [Page 6]
