# Content Steering Beyond Multi-CDN: Intra-CDN Edge Cache Switching as a Use Case

Burak Kara, Gwendal Simon

► To cite this version:

Burak Kara, Gwendal Simon. Content Steering Beyond Multi-CDN: Intra-CDN Edge Cache Switching as a Use Case. MHV 2026 - 5th Mile-High Video Conference, Feb 2026, Denver, United States. pp.102-107, 10.1145/3789239.3793279 . hal-05525920

HAL Id: hal-05525920

https://inria.hal.science/hal-05525920v1

Submitted on 24 Feb 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Content Steering Beyond Multi-CDN: Intra-CDN Edge Cache Switching as a Use Case

Burak Kara†*, Gwendal Simon†

†Synamedia, *Inria

Rennes, France

## Abstract

Content Delivery Network (CDN) operators cannot reliably migrate active streaming sessions across Edge Cache Servers (ECSs) for maintenance, load balancing, failure recovery, or energy-aware consolidation without disrupting playback. Content steering, standardized for multi-CDN orchestration in DASH and HLS, provides a control loop that can be repurposed for this intra-CDN problem. Although interpreted as steering across distinct CDNs, the standard treats pathway identifiers as opaque labels and does not require them to map to different providers. We present an architectural use case that leverages this flexibility to either force traffic-router reentry within the same CDN or directly target specific ECSs, with a CDN control plane computing reassignment decisions and the Content Steering Server (CSS) enforcing them by cloning pathways or updating pathway priorities. The approach requires no player changes beyond existing content steering support, and bounds migration latency by the steering Time to Live (TTL) as a standards-aligned alternative to mid-session reassignment mechanisms.

## CCS Concepts

* Information systems → Multimedia streaming.

## Keywords

Content Delivery Networks, Content Steering, Edge Cache Servers, Video Streaming, DASH, HLS

## 1 Introduction

Content Delivery Networks (CDNs) form the backbone of large-scale video streaming by mapping each viewer to a nearby Edge Cache Server (ECS) at startup, typically through DNS resolution or HTTP redirection [15]. Once playback begins, the assigned ECS typically remains fixed since HTTP stacks reuse established connections (TCP or QUIC) for segment retrieval until the connection closes. This static binding is simple to operate but prevents mid-session flexibility. Consequently, changes in ECS conditions cannot be reflected in the delivery path of active clients immediately.

Several recurring scenarios expose the limitations of fixed ECS mappings. An ECS may degrade due to hardware faults, software failures, or network anomalies, yet active sessions remain anchored and experience reduced throughput. Planned maintenance on an ECS requires draining sessions before shutdown, forcing a CDN either to wait for natural termination (which often takes hours) or to risk playback disruption. Shifts in demand and user mobility, such as transitions between Wi-Fi and cellular networks, create load imbalances where some ECSs are overloaded while others remain

underutilized. Static mappings also prevent energy-aware consolidation, where a CDN could migrate sessions onto fewer active ECSs and power down idle nodes during off-peak periods [11].

Existing mechanisms for mid-session reassignment are inadequate. DNS-based routing fails to manipulate established connections immediately since mapping occurs at startup and is further constrained by connection reuse and resolver caching delays [12]. HTTP redirects are inconsistently honored by video players once playback begins [21]. Per-client manifest rewriting depends on refetching timing and introduces operational complexity at scale. As a result, CDN operators lack a standards-based mechanism to reassign active sessions without disrupting playback.

In this paper, we propose an architectural use case for mid-session ECS switching within a single CDN, where we focus on migration across geographically or logically distinct ECSs or Point-of-Presences (PoPs). Content steering [3, 17] defines a control loop in which players periodically query a Content Steering Server (CSS) and receive steering instructions. The standard is motivated by steering clients between multiple CDNs mid-session, where pathways map to distinct CDN providers. However, this distinct mapping is not strictly constrained, since pathway identifiers are opaque labels. The corresponding URIs are resolved and routed according to the underlying CDN policies. By configuring content steering responses to reference either distinct ECSs directly or alternative hostnames that resolve within the same CDN, we specify two switching mechanisms based on pathway cloning and pathway-priority adjustment, with decisions driven by control-plane telemetry and enforced through the CSS. We then analyze control plane overhead, latency bounds, and operational constraints to assess when intra-CDN ECS switching is feasible without modifications beyond standard content steering support.

The remainder of this paper is organized as follows. Section 2 elaborates on the background and reviews related work. Section 3 introduces the system architecture and details the pathway cloning and pathway-priority adjustment mechanisms. Section 4 presents the feasibility analysis, and Section 5 concludes the paper.

## 2 Background and Related Work

This section summarizes why common CDN request-routing mechanisms are ineffective for mid-session reassignment and reviews the standardized content steering control loop that we repurpose for intra-CDN ECS switching. We then position the use case relative to adjacent protocols and multi-CDN orchestration practice.

Request routing maps clients to ECSs while balancing proximity, latency, load, and cache locality under time-varying demand [18]. In practice, these routing mechanisms primarily influence *session start*, whereas streaming sessions remain pinned to the initially selected endpoint due to transport connection reuse.

<figure><img src="image_2.png" /></figure>

This work is licensed under a Creative Commons Attribution 4.0 International License.
DNS-based routing is the dominant mechanism for CDN request mapping. When a client resolves a CDN hostname, authoritative DNS selects ECS addresses using resolver location and telemetry [1]. However, DNS is consulted at startup, and HTTP stacks typically reuse established transport connections (TCP or QUIC) for segment retrieval until the connection closes [6, 22]. Resolver caching further delays DNS updates, with effective propagation latencies that can extend to hours even under aggressive Time to Live (TTL) settings [12]. Commercial global traffic management systems build on this model (e.g., Akamai GTM<fnref n="1" />, Cloudflare Load Balancing<fnref n="2" />, and AWS Global Accelerator<fnref n="3" />), and therefore primarily assign new sessions rather than moving active ones.

Anycast complements DNS by announcing the same IP prefix from multiple PoPs via Border Gateway Protocol (BGP), letting Internet routing select a nearby announcement and providing failover [7]. Nevertheless, Anycast does not offer controlled mid-session reassignment, and routing changes can break existing connections rather than enable orderly migration [4]. Within a single PoP, Layer-4 load balancers can migrate sessions seamlessly across co-located servers using consistent hashing and connection tracking [16]. However, these mechanisms operate under a shared IP prefix and do not extend to migration across geographically distributed PoPs with distinct addresses.

Application-layer mechanisms provide finer control but depend on player behavior. HTTP redirection with 3XX responses can, in principle, steer subsequent segment requests [5], yet redirect handling after startup is inconsistent across players and can be undermined by continued connection reuse [21]. Manifest manipulation can embed ECS-specific URLs [15], but mid-session changes require manifest refetch and reparse, which is typically infrequent and introduces operational overhead, including per-client state and cache-key proliferation.

Overall, these approaches provide limited or nonstandard control in mid-session. They either act primarily at session start (DNS and Anycast) or rely on client behaviors that are not consistently enforced across players (redirects and manifest manipulation).

Beyond routing, several related mechanisms address endpoint selection or session continuity, but they do not directly enable standards-based ECS reassignment for active sessions. Application-Layer Traffic Optimization (ALTO) (RFC 7285) exposes abstract network maps and costs to guide endpoint selection [20]. However, ALTO is advisory and does not provide an enforcement mechanism to redirect an established session. QUIC connection migration (RFC 9000) preserves transport continuity when a client changes network attachment (e.g., Wi-Fi to cellular) [9], but it retains the server endpoint and therefore does not realize ECS switching.

Client-side server selection has been proposed as an alternative to DNS-centric mapping by letting clients probe multiple candidates and dynamically choose the best-performing replica [10]. For instance, Go-with-the-Winner uses lightweight client-side measurements to select among servers and improve performance [10]. Similarly, DASH manifests can advertise multiple BaseURL elements, allowing players to fall back autonomously upon failure. However, such client-driven approaches lack server-side control where the

CDN cannot direct a specific session to a designated ECS based on operational objectives. Content steering addresses this gap by providing a server-directed mechanism that remains interoperable across heterogeneous players.

At the inter-CDN layer, multi-CDN orchestration platforms map sessions across providers based on performance, cost, or availability signals. Enforcement relies on proprietary player logic, DNS steering, or manifest manipulation, which inherits the mid-session constraints summarized above.

Recent work also examined the multi-CDN brokering ecosystem and the implications of broker decisions that are opaque to CDNs [13, 14]. Mukerjee et al. analyze how brokers can complicate delivery objectives and propose redesigned broker-CDN interaction models to better align cost and performance goals [13, 14]. Gama et al. explore content steering for adaptive streaming in edge-cloud environments, focusing on multi-tier placement rather than intra-CDN ECS migration [8]. These efforts focus on inter-CDN coordination or edge-cloud orchestration, whereas we target intra-CDN ECS switching using a control loop that is already standardized and increasingly supported by players.

Content steering is a standards-based control framework for adapting delivery selection during an active streaming session. DASH and HLS define complementary specifications [3, 17] that share a common model where the manifest advertises multiple pathways (identified by opaque labels) and a CSS endpoint. During playback, the player periodically queries the CSS and receives a JSON response that specifies pathway ordering via PATHWAY-PRIORITY and a directive lifetime via TTL. Optional fields support changing the CSS endpoint (i.e., RELOAD-URI) and defining new pathways at runtime through PATHWAY-CLONES, which applies URI-rewrite rules to derive a new pathway from an existing one without modifying the manifest. Reznik et al. provide an overview of the standard motivation and design trade-offs beyond the specifications [19].

Operationally, the player extracts the CSS URL and available pathways from the manifest, then polls the CSS at the specified cadence. After receiving a response, the player selects the highest-priority available pathway (including any synthesized clones) and applies the updated configuration at segment boundaries. When the TTL expires, the player refreshes directives by requerying the CSS, enabling session-aware control through standardized signaling.

The standard was designed for multi-CDN orchestration, where distinct pathways commonly map to independent CDN providers. In this context, pathway labels such as cdn-a and cdn-b reference separate infrastructures, and the CSS orchestrates traffic distribution across organizational boundaries. However, the specification imposes no constraint requiring pathways to map to distinct providers [3, 17]. Pathway identifiers are treated as labels with no prescribed semantic relationship to the underlying delivery infrastructure, and the actual ECS serving a pathway is determined by URI resolution and the internal routing logic of the CDN. Consequently, steering responses that reorder pathways, or introduce cloned pathways with modified URI patterns, can redirect clients to different ECSs within the same CDN. This observation forms the basis of our intra-CDN ECS switching use case.

<footnote n="1">¹https://www.akamai.com/products/global-traffic-management</footnote>

<footnote n="2">²https://developers.cloudflare.com/load-balancing/</footnote>

<footnote n="3">³https://aws.amazon.com/global-accelerator/</footnote>
# 3 Intra-CDN Edge Cache Switching

This section describes the architecture of the proposed intra-CDN ECS switching framework, detailing the system components and their interactions.

## 3.1 Architectural Overview

The architecture follows the standard content steering deployment model and requires no structural modifications to the existing CDN infrastructure. Figure 1 illustrates the organization. The system comprises six components interacting across two planes. The *data plane* carries media segments from ECSs to players, while the *control plane* aggregates telemetry and issues reassignment decisions. The only added coupling is an interface from the control plane to the CSS. Rather than steering clients across CDN providers, the control plane uses this interface to drive intra-CDN routing decisions, allowing mid-session ECS reassignment through standard steering responses.

<figure><img src="image_3.png" /><figcaption>Figure 1: Architecture of intra-CDN ECS switching. The control plane aggregates telemetry from ECSs and issues switch instructions to the CSS. The CSS updates steering responses, prompting sessions to reconnect via the traffic router or directly to designated ECSs.</figcaption></figure>

All components are standard in content steering deployments, and the distinction lies in how they are coordinated for intra-CDN switching.

The **manifest creator** generates media manifests that include content steering metadata and advertise at least one delivery pathway. Optionally, manifests may advertise multiple pathways that either (i) resolve to the CDN ingress via alternative hostnames or (ii) directly reference distinct ECSs, depending on the switching mechanism used in Section 3.2.

The **video player** retrieves the manifest, initiates playback, and periodically queries the CSS according to the steering TTL. Upon receiving updated pathway priorities or clone definitions, it synthesizes any cloned pathways and switches at segment boundaries without additional application logic beyond standard content steering support.

The **traffic router** is the CDN ingress point that performs initial session-to-ECS assignment. It also supports mid-session reassignment when steering directs a client to a hostname that resolves

back to the ingress. In that case, the player re-enters the CDN and the traffic router applies policy and telemetry to select a new ECS.

The **ECSs** serve media segments and export operational telemetry to the control plane, including session counts, throughput utilization, latency, and cache hit ratio. If available, they may also export per-session signals derived from player or client-side measurements (e.g., Quality of Experience (QoE) via Common Media Client Data (CMCD) version 1) to support decision-making.

The **control plane** aggregates telemetry across ECSs, correlates it with operational inputs such as maintenance schedules or failure signals, and determines when reassignment is warranted. It issues *switch instructions* to the CSS, specifying which sessions to steer and, depending on the mechanism, optionally the target ECS hostname.

The **CSS** enforces reassignment decisions by generating content steering responses. To remain CDN-agnostic, the CSS does not require visibility into internal CDN topology or real-time session placement and instead relies on control-plane instructions when updating pathway priorities or issuing pathway clones.

## 3.2 Switching Mechanisms

The CSS selects the mechanism based on the switch instruction and the pathways advertised in the manifest. If the instruction specifies a target ECS URI, the CSS uses pathway cloning to direct the player to that endpoint. If no target URI is provided and the manifest advertises multiple pathways, the CSS triggers switching by reordering PATHWAY-PRIORITY to promote an alternative pathway. If no target URI is provided and only a single pathway is available, the CSS again uses pathway cloning, but targets a distinct CDN ingress hostname to force traffic-router reentry.

### 3.2.1 Pathway Cloning
Pathway cloning allows the CSS to introduce new delivery pathways at runtime without modifying the media manifest (e.g., MPD in DASH and playlist in HLS). In the content steering response, the CSS includes a PATHWAY-CLONES entry that names a base pathway and specifies a URI rewrite pattern. The player applies this transformation locally to synthesize a cloned pathway and then uses the clone for subsequent segment requests after processing the response.

We use pathway cloning in two modes.

In *direct ECS targeting*, as illustrated in Figure 2, the switch instruction includes a target ECS URI, and the CSS issues a clone whose rewritten hostname points to that specific endpoint. The player resolves the target and establishes a new connection directly to the designated ECS, avoiding additional indirections through the CDN ingress point (e.g., traffic router).

In *CDN reentry*, the switch instruction omits a target ECS. The CSS issues a clone that rewrites the hostname to an alternative ingress name that resolves to the traffic router. An example content steering response is given in Figure 3. The alternative hostname must differ from the currently used hostname to reduce the likelihood of reusing cached DNS resolutions. The player resolves the new hostname, re-enters the CDN via the traffic router, and is reassigned to an ECS according to current routing policy and telemetry.

Direct targeting provides deterministic, low-latency reassignment but requires the control plane to select the destination ECS. Reentry delegates placement to existing routing infrastructure and
```json
{
  ...
  PATHWAY-PRIORITY: ["ec2", "main"],
  PATHWAY-CLONES: [{
    BASE-ID: "main",
    ID: "ec2",
    URI REPLACEMENT: {
      HOST: "ecs2.cdn.com",
      PARAMS: { "id": "fc56e2a76315" }
    }
  }]
}
```

<caption>Figure 2: Content steering response instructing pathway cloning for direct ECS targeting.</caption>

```json
{
  ...
  PATHWAY-PRIORITY: ["reentry", "main"],
  PATHWAY-CLONES: [{
    BASE-ID: "main",
    ID: "reentry",
    URI REPLACEMENT: {
      HOST: "reentry.cdn.com",
      PARAMS: { "id": "fc56e2a76315" }
    }
  }]
}
```

<caption>Figure 3: Content steering response instructing pathway cloning for CDN reentry.</caption>

requires only ingress hostnames, at the cost of reduced determinism.

### 3.2.2 Pathway-Priority Adjustment.
When the media manifest advertises multiple pathways, the CSS can trigger switching by updating the `PATHWAY-PRIORITY` list, as in Figure 4. Promoting a secondary pathway to highest priority causes the player to transition to that pathway when it processes the next steering response. This mechanism avoids dynamic pathway creation but requires provisioning alternative pathways in advance.

A practical configuration is to advertise multiple ingress hostnames that all resolve to the same traffic router. By promoting a different ingress hostname, the CSS encourages a fresh DNS lookup and a new connection establishment, after which the traffic router can assign an ECS under current policy. This approach scales with the number of ECSs and PoPs since it requires only a small, fixed set of generic reentry pathways in the manifest.

Alternatively, manifests can advertise pathways that directly correspond to specific ECSs or PoPs. This configuration supports planned operations where targets are known ahead of time, but it couples manifests to infrastructure details and scales poorly as ECSs are added, removed, or renumbered.

```json
{
  ...
  PATHWAY-PRIORITY: ["reentry", "ecs2", "main"],
}
```

<caption>Figure 4: Content steering response with pathway-priority adjustment.</caption>

## 3.3 Migration Triggers

The control plane issues switch instructions in response to operational objectives and observed service conditions. We distinguish selective and bulk triggers based on the scope of affected sessions.

Selective migration targets individual sessions or cohorts selected by policy. Typical triggers include persistent QoE degradation inferred from client-side telemetry (e.g., CMCD) [2], correlated increases in rebuffering or segment download time, access-network transitions, or operator policies that apply to specific regions or customer tiers. Selective migration requires the control plane to identify the affected sessions and submit switch instructions for those sessions only.

Bulk migration targets all sessions currently served by an ECS or a PoP. Common triggers include planned maintenance, failure recovery, rapid load shedding during overload, and energy-aware consolidation when an operator intends to drain and deactivate underutilized nodes. In bulk mode, the control plane enumerates the affected sessions using available CDN telemetry and issues switch instructions at scale.

For either mode, if direct ECS targeting is desired, the control plane includes the destination URI in the instruction; otherwise, it can request CDN reentry and delegate final placement to the traffic router.

```json
{
  "target-clients": <List of client identifiers>,
  "target-ecs": <-Optional- List of target ECS URIs>
}
```

<caption>Figure 5: Migration instruction from control plane to CSS.</caption>

## 3.4 Latency Bounds

Migration latency is bounded by the content steering polling interval implied by the steering TTL and by the time required to establish a new delivery path. In the worst case, a session queries the CSS immediately before the control plane issues a switch instruction, and the session applies the change only after the next steering refresh, yielding a bound of approximately one TTL. After the content steering update is received, additional delay comes from (i) DNS resolution for the newly selected hostname, (ii) TCP and TLS handshake overhead for connection establishment (typically 2 to 4 round trips for TLS 1.3), and (iii) applying the change at a segment boundary, which is constrained by the segment request cadence. Furthermore, Adaptive Bitrate (ABR) algorithms that rely on smoothed throughput estimates may temporarily underestimate
available bandwidth after switching, since historical measurements
from the previous ECS no longer reflect the new path.

Operators can reduce reassignment delay by configuring shorter
TTL values, trading faster reaction for higher CSS query load. For
urgent migrations, the CSS can respond to flagged sessions with a
reduced TTL, accelerating the next refresh without globally chang-
ing the polling behavior.

In contrast, DNS-based reassignment cannot reliably affect es-
tablished transport connections, and even for new connections,
DNS updates may be delayed by resolver caching with effective
propagation latencies extending to hours [12]. Content steering
operates within the active session and provides a standards-based
mechanism to initiate a controlled reconnection to a new hostname
or endpoint at segment boundaries.

4 Feasibility Analysis

This section analyzes the feasibility of intra-CDN steering by quanti-
fying control-plane overhead, discussing player-side requirements,
outlining operational constraints, and examining interaction with
multi-CDN steering. The goal is to identify when standards-based
steering provides practical advantages over DNS- and redirect-
based techniques for active sessions. This section provides a feasi-
bility analysis grounded in standardized protocol behavior and prior
DNS measurement studies [12], and leaves implementation-level
evaluation to future work.

4.1 Control-Plane Overhead

In content steering, each active session queries the CSS approxi-
mately once per TTL interval. For *N* concurrent sessions and a TTL
of *T* seconds, the expected query rate is *N*/*T* requests per second.
For instance, *N* = 100,000 and *T* = 30 s yields ≈ 3333 queries per
second, which is modest for stateless HTTP services and can be
handled via horizontal scaling and caching of common responses.
Since steering responses are small JSON objects (typically ≤ 1 kB),
bandwidth overhead is similarly moderate.

The control plane must additionally maintain steering state at
session granularity for sessions under active management. A min-
imal record includes a session identifier, current pathway (or in-
ferred ECS), and an optional target or policy tag. Even with tens
of bytes per record, storing state for 100,000 sessions requires only
single-digit megabytes. Under steady state, updates are sparse and
driven by exceptional events (e.g., degradation, maintenance). Dur-
ing bulk migration, the update rate can spike as many sessions are
marked simultaneously, but the CSS does not require strong con-
sistency to be effective: it suffices that sessions eventually receive
updated priorities or clone directives within their next steering
refresh window.

4.2 Player Compatibility

The mechanism assumes players that implement content steering
according to the DASH or HLS specifications [3, 17]. For deploy-
ments with heterogeneous clients, non-supporting players remain
bound to their initial ECS, and operators continue to rely on con-
ventional request routing for those sessions.

Importantly, standards compliance does not imply identical run-
time behavior. Implementations may differ in how they handle

CSS timeouts, malformed responses, aggressive TTL values, or fre-
quent pathway reordering. Some players may also enforce local
hysteresis (e.g., minimum time between switches) to avoid oscilla-
tion. Operationally, this variability implies that operators should
validate content steering behavior against their target player mix
and implement conservative policies at the CSS, such as limiting
the rate of pathway changes per session and always advertising
viable fallback pathways.

4.3 Operational Constraints

Several practical constraints bound applicability. First, manifests
must expose content steering semantics. Legacy single-endpoint
manifests without content steering metadata cannot benefit from
the approach without regeneration.

Second, content must remain consistently addressable across
candidate ECSs. Switching is only transparent if segment URLs
remain valid after reassignment and if the destination ECS can
serve the requested segments (from cache or via origin fetch) un-
der the same naming and authorization scheme. Operationally, this
requires consistent cache key construction and compatible tokeniza-
tion or URL-signing across the targeted ECSs. Moreover, manifest
propagation delays across ECSs can cause transient inconsistencies
where a player may request segments that exist on the origin but
have not yet been cached or indexed at the newly assigned ECS,
resulting in cache misses or temporary errors during live events.

Third, session affinity introduced by server-side state can limit
transparent switching. Examples include Digital Rights Manage-
ment (DRM) workflows that bind licenses or keys to specific end-
points, personalized ad insertion that relies on per-session server
state, or edge-side session pinning for measurement or policy en-
forcement. DRM license servers may require re-validation or re-
issuance of keys when the delivery endpoint changes, potentially
causing playback interruption if license acquisition is not seamless.
Such cases may require additional coordination beyond content
steering to avoid disruptions during reassignment. Common miti-
gations include shared state stores accessible from multiple ECSs,
session-identifier-based state lookup that decouples state from end-
point identity, and replicated DRM license services.

4.4 Interaction with Multi-CDN Steering

When a content provider employs content steering for multi-CDN
orchestration, intra-CDN steering must coordinate with the CSS
operated by the provider. Two deployment models address this
interaction.

In the *hierarchical model*, provider-level pathways correspond
to CDN identifiers (e.g., cdn-a, cdn-b), and each CDN internally
augments steering responses with ECS-level pathway clones. The
provider-side CSS selects the CDN, while the CDN control plane re-
fines the selection to a specific ECS by injecting clones that override
only the host component of URIs within that CDN namespace.

In the *interposition model*, the CDN operates a proxy CSS that in-
tercepts player requests, queries the provider-side CSS, and merges
intra-CDN directives before responding. This approach provides
full control but requires the CDN to maintain session state mapping
provider pathways to internal ECSs.
Conflicts may arise if both layers attempt simultaneous redirection or advertise inconsistent TTL values. Operational policies should define precedence rules, typically prioritizing provider directives for inter-CDN decisions while allowing CDN autonomy for intra-CDN placement.

## 5 Conclusion and Future Work

This paper presented a standards-driven architectural use case for intra-CDN ECS switching using DASH and HLS content steering. We showed how existing content steering primitives, originally motivated by multi-CDN orchestration, can be repurposed within a single CDN by interpreting pathways as either ingress hostnames for traffic-router reentry or direct ECS targets. Using pathway cloning and pathway-priority adjustment, the CSS can enforce mid-session reassignment at segment boundaries without player modifications beyond standard content steering support. Compared with DNS-based routing, HTTP redirects, and manifest rewriting, this approach provides a session-aware control loop whose reaction time is bounded by the content steering TTL and whose enforcement is portable across compliant player implementations.

This paper provides an architectural framework and feasibility analysis; experimental validation remains for future work. Several concrete directions warrant investigation. First, a prototype implementation is needed to quantify end-to-end reassignment latency under realistic segment durations, DNS caching behavior, and TCP/TLS connection establishment costs, and to measure the resulting QoE impact (rebuffering events, bitrate drops) during switching. Second, production-oriented policy design warrants study, including stability controls (e.g., hysteresis and rate limits), fairness across session cohorts, and safeguards against oscillation during correlated failures. Third, the interaction between switching and stateful workflows (e.g., DRM license re-validation, personalized ad insertion, and token-based authorization) should be characterized to identify when shared-state or indirection mechanisms are required. Fourth, the coexistence of intra-CDN and multi-CDN content steering deserves further formalization, particularly conflict resolution strategies when provider and CDN control planes issue concurrent directives. Finally, large-scale deployment would benefit from operational guidance on TTL selection, CSS scaling, and telemetry requirements for identifying and targeting affected sessions during bulk migrations.

## References

[1] Matt Calder, Ashley Flavel, Ethan Katz-Bassett, Ratul Mahajan, and Jitendra Padhye. 2015. Analyzing the Performance of an Anycast CDN. In *ACM IMC*. doi:10.1145/2815675.2815717

[2] Consumer Technology Association. 2020. Web Application Video Ecosystem – Common Media Client Data (CMCD). https://shop.cta.tech/collections/standards/products/web-application-video-ecosystem-common-media-client-data-cta-5004. Accessed on May 26, 2025.

[3] DASH-IF. [n. d.]. Content Steering for DASH. https://www.etsi.org/deliver/etsi-ts/103900_103999/103998/01.01.01_60/ts_103998v010101p.pdf.

[4] Wouter B. de Vries, Ricardo de O. Schmidt, Wes Hardaker, John Heidemann, Pieter-Tjerk de Boer, and Aiko Pras. 2017. Broad and load-aware anycast mapping with verf Klooper. In *ACM IMC*. doi:10.1145/3131365.3131371

[5] Roy T. Fielding, Mark Nottingham, and Julian Reschke. 2022. HTTP Semantics. doi:10.17487/RFC9110

[6] Roy T. Fielding, Mark Nottingham, and Julian Reschke. 2022. HTTP/1.1. doi:10.17487/RFC9112

[7] Ashley Flavel, Pradeepkumar Mani, David Maltz, Nick Holt, Jie Liu, Yingying Chen, and Oleg Surmachev. 2015. FastRoute: A Scalable Load-Aware Anycast Routing Architecture for Modern CDNs. In *USENIX NSDI*. https://www.usenix.org/conference/nsdi15/technical-sessions/presentation/flavel

[8] Eduardo S. Gama, Roberto Rodrigues-Filho, Edmundo R. M. Madeira, Roger Immich, and Luiz F. Bittencourt. 2024. Enabling Adaptive Video Streaming via Content Steering on the Edge-Cloud Continuum. In *IEEE ICFEC*. doi:10.1109/ICFEC61590.2024.00018

[9] Jana Iyengar and Martin Thomson. 2021. QUIC: A UDP-Based Multiplexed and Secure Transport. doi:10.17487/RFC9000

[10] Chang Liu, Ramesh K. Sitaraman, and Don Towsley. 2016. Go-with-the-winner: Performance based client-side server selection. In *IFIP Networking*. doi:10.1109/IFIPNetworking.2016.7497248

[11] Vimal Mathew, Ramesh K Sitaraman, and Prashant Shenoy. 2012. Energy-aware load balancing in content delivery networks. In *IEEE INFOCOM*. doi:10.1109/INFOCOM.2012.6195846

[12] Giovane C. M. Moura, John Heidemann, Ricardo de O. Schmidt, and Wes Hardaker. 2019. Cache Me If You Can: Effects of DNS Time-to-Live. In *IMC '19*. doi:10.1145/3355369.3355568

[13] Matthew K. Mukerjee, Ilker Nadi Bozkurt, Bruce Maggs, Srinivasan Seshan, and Hui Zhang. 2016. The Impact of Brokers on the Future of Content Delivery. In *ACM HotNets*. doi:10.1145/3005745.3005749

[14] Matthew K. Mukerjee, Ilker Nadi Bozkurt, Devdeep Ray, Bruce M. Maggs, Srinivasan Seshan, and Hui Zhang. 2017. Redesigning CDN-Broker Interactions for Improved Content Delivery. In *CoNEXT*. doi:10.1145/3143361.3143366

[15] Erik Nygren, Ramesh K. Sitaraman, and Jennifer Sun. 2010. The Akamai network: a platform for high-performance internet applications. *SIGOPS Oper. Syst. Rev.* (2010). doi:10.1145/1842733.1842736

[16] Vladimir Olteanu, Alexandru Agache, Andrei Voinescu, and Costin Raiciu. 2018. Stateless Datacenter Load-balancing with Beamer. In *USENIX NSDI*. https://www.usenix.org/conference/nsdi18/presentation/olteanu

[17] Roger Pantos and Eryk Vershen. 2025. Content Steering. https://datatracker.ietf.org/doc/draft-pantos-content-steering/01/ Work in Progress.

[18] Al-Mukaddim Khan Pathan, Rajkumar Buyya, et al. 2007. A taxonomy and survey of content delivery networks. *Grid computing and distributed systems laboratory, University of Melbourne, Technical Report* (2007).

[19] Yuriy Reznik, Guillem Cabrera, Daniel Silhavy, Stefan Pham, Alex Giladi, Alex Balk, Ali C. Begen, and Will Law. 2024. Content Steering: a Standard for Multi-CDN Streaming. In *ACM MHV*. doi:10.1145/3638036.3640293

[20] Stanislav Shalunov, Wendy Roome, Richard Woundy, Stefano Previdi, Sebastian Kiesel, Richard Alimi, Reinaldo Penno, and Y. Richard Yang. 2014. Application-Layer Traffic Optimization (ALTO) Protocol. doi:10.17487/RFC7285

[21] Miran Taha and Aree Ali. 2023. Redirection and Protocol Mechanisms in Content Delivery Network-Edge Servers for Adaptive Video Streaming. *Applied Sciences* 13, 9 (2023). doi:10.3390/app13095386

[22] Martin Thomson and Cory Benfield. 2022. HTTP/2. doi:10.17487/RFC9113