Source-linked AI summary
Dissecting Apple's Meta-CDN during an iOS Update
Jeremias Blendin, Fabrice Bendfeldt, Ingmar Poese, Boris Koldehofe, Oliver Hohlfeld
TL;DR
Research on Meta-CDNs has focused mainly on third-party services, leaving self-operated models that combine an organization’s own infrastructure with third-party CDNs less understood. The paper analyzes Apple’s mapping, cache infrastructure, and iOS update rollout using global measurements and traffic data from a European ISP. During the update, third-party CDN traffic spikes reached 438%, and overflow saturated seemingly unrelated links.
Problem
Self-operated Meta-CDNs that combine a content provider’s infrastructure with third-party CDNs remain little understood, despite being used to supplement infrastructure or handle overload.
Source: §1 · p. 1Method
The authors characterize Apple’s Meta-CDN through global RIPE Atlas DNS measurements, update-rollout observations, and correlated traffic traces from a European ISP.
Source: §1 · p. 1Results
Third-party CDN traffic spikes reached 438%, offload distribution changed daily, and overflow saturated seemingly unrelated links during the iOS update.
Source: §1 · p. 2Takeaways & Limitations
The update’s CDN assignments and overflow made traffic difficult for ISPs to predict and could affect seemingly unrelated peering connections.
Source: §6 · p. 6Actual traffic during the update was available only for a single European Eyeball ISP, not globally.
Source: §4 · p. 4
Abstract
from arXiv · showhide
Content delivery networks (CDN) contribute more than 50% of today's Internet traffic. Meta-CDNs, an evolution of centrally controlled CDNs, promise increased flexibility by multihoming content. So far, efforts to understand the characteristics of Meta-CDNs focus mainly on third-party Meta-CDN services. A common, but unexplored, use case for Meta-CDNs is to use the CDNs mapping infrastructure to form self-operated Meta-CDNs integrating third-party CDNs. These CDNs assist in the build-up phase of a CDN's infrastructure or mitigate capacity shortages by offloading traffic. This paper investigates the Apple CDN as a prominent example of self-operated Meta-CDNs. We describe the involved CDNs, the request-mapping mechanism, and show the cache locations of the Apple CDN using measurements of more than 800 RIPE Atlas probes worldwide. We further measure its load-sharing behavior by observing a major iOS update in Sep. 2017, a significant event potentially reaching up to an estimated 1 billion iOS devices. Furthermore, by analyzing data from a European Eyeball ISP, we quantify third-party traffic offloading effects and find third-party CDNs increase their traffic by 438% while saturating seemingly unrelated links.
1 INTRODUCTION
The paper examines an understudied self-operated Meta-CDN model through Apple’s CDN, which combines its own delivery infrastructure with third-party CDNs. It traces Apple’s mapping and update load-sharing behavior and finds substantial, dynamic third-party offloading with consequences for ISP links.
1 INTRODUCTION
- Publishing content on multiple CDNs adds a request-mapping layer, while single-CDN customers remain bound to that CDN’s cost model, performance, and geographic distribution.CDNs can account for more than half of an ISP’s traffic.Source: §1 · p. 1
- Third-party Meta-CDN services have received study, but little is known about content providers that combine their own infrastructure with third-party CDNs.Such providers can use third-party CDNs to supplement their infrastructure, for example, to handle overload.Source: §1 · p. 1
- The paper characterizes Apple’s self-operated Meta-CDN, including its involved CDNs, request mapping, and cache locations, and examines update load sharing and ISP traffic effects.The analysis includes more than 800 RIPE Atlas probes and correlates DNS measurements with traffic data from a European ISP.Source: §1 · p. 1
- Third-party CDN traffic spikes reached 438%, offload distribution changed daily, and overflow saturated seemingly unrelated links during the iOS update.The study analyzes traffic from a European Eyeball ISP.Source: §1 · p. 2
2 BACKGROUND & RELATED WORK
Multihoming content across CDNs can offer cost reductions and higher availability, but requires an additional mapping layer. Third-party Meta-CDN mapping policies are often unknown to ISPs, making demand harder to predict.
2 BACKGROUND & RELATED WORK
- Multihomed content can use different CDN prices and traffic-volume contracts and may offer higher availability in high-load scenarios, but requires an additional request-mapping layer.Source: §2 · p. 2
- Third-party Meta-CDN request mapping is unknown to participating content providers, making demand and traffic harder for Eyeball ISPs to predict.The passage links this lack of information to unexpected traffic skews and short-timescale demand variance.Source: §2 · p. 2
3 DISSECTING THE APPLE CDN
The paper traces how iOS devices discover and download updates, how Apple maps requests across its own and third-party CDNs, and how Apple’s cache sites are structured. Measurements combine device traffic analysis, DNS and traceroute probes, and server checks.
3.1 iOS Device Behavior
- iOS devices check for updates hourly by downloading two manifests; when a user initiates an available update, the update file is downloaded from appldnld.apple.com over HTTP.The first manifest contained about 1,800 device and OS-version entries as of July 2017; the study did not observe use of the second manifest.Source: §3.1 · p. 2
3.2 CDN Selection Process
- Apple’s update delivery combines its own cache infrastructure with third-party CDNs, and only IPv4 resolution was observed at the mapping entry points.Source: §3.2 · pp. 2–3, §3.3 · p. 4
- The measurement design used nine AWS VMs for recursive DNS and file-availability checks, 800 global RIPE Atlas probes for DNS and traceroutes, and 400 probes inside a European ISP.Global probes queried every five minutes for a week before and after the September 19, 2017 iOS 11 release; ISP probes measured every 12 hours from August 20 to December 31.Source: §3.2 · p. 2
- Apple’s mapping uses three selection steps: Akamai distinguishes India and China from other regions, Apple selects its or a third-party CDN, and Akamai DNS selects among third-party CDNs.The Apple CDN selection DNS name has a 15-second TTL for quick reroutes; the study did not examine India and China further because probe density there was low.Source: §3.2 · pp. 2–3
3.3 Apple’s Own CDN Infrastructure
- Apple’s delivery-site naming analysis identified 34 cache sites, and HTTP headers revealed requests pass through vip-bx load balancers to four associated edge-bx nodes before forwarding to edge-lx if needed.The study inferred that a single Apple CDN IP represents the download capacity of four edge-bx servers.Source: §3.3 · pp. 3–4
4 CHARACTERIZING THE APPLE CDN DURING AN IOS UPDATE ROLLOUT
During the September 2017 iOS 11 rollout, Apple’s Meta-CDN shifted delivery toward third-party CDNs, especially in Europe. The update also presented ISP traffic challenges because CDN assignments and overflow could affect links beyond the expected delivery paths.
4 CHARACTERIZING THE APPLE CDN DURING AN IOS UPDATE ROLLOUT
- Europe’s unique cache IP count peaked at 977 after the release, versus a pre-update two-day average of 191, with much of the increase from Limelight and some from Akamai.Europe was the only continent with a considerable post-update spike; about 50% of observed European IPs belonged to third-party CDNs.Source: §4 · p. 4
- Inside the measured European ISP, Akamai CDN IPs rose 408% from September 18 to September 20, while Apple’s CDN IP count remained somewhat stable.The authors interpret the stable Apple IP count as indicating demand could not be satisfied by Apple’s infrastructure alone and needed third-party delegation.Source: §4 · pp. 4–5, Figure 5 · p. 5
- Apple handled the update flash crowd on a per-continent basis and delegated European traffic to third-party CDNs, without observed proactive mapping changes before release.The Akamai IP increase took six hours to reach its load-dependent peak.Source: §4 · pp. 4–5
- ISP operators faced unpredictable CDN assignments and overflow traffic that could fully saturate seemingly unrelated peering links.The study’s global measurements count DNS-observed cache IPs; actual traffic during the event was available only for one European Eyeball ISP.Source: §4 · pp. 4–5, Figure 6 · p. 5
5 ISP PERSPECTIVE ON A META-CDN
The ISP analysis distinguishes Apple-controlled offload from CDN-controlled overflow, then measures how both affect traffic during the iOS update. Offload choices were difficult to predict, while Limelight overflow saturated seemingly unrelated peering links.
5.1 Definition of offload and overflow Traffic
- Offload is Apple Meta-CDN traffic served by third-party CDN servers, while overflow arrives through non-direct neighbors; the two can overlap.Offload is controlled by Apple’s Meta-CDN, whereas individual CDN load balancers handle overflow, creating independent control loops that complicate traffic prediction.Source: §5.1 · p. 5
5.2 ISP Measurement Setup
- The ISP analysis used border-router BGP, Netflow, and SNMP measurements from Sep. 15–23, cross-correlating observed Apple Meta-CDN server IPs with traffic flows and source ASes.The collection comprised about 300 billion Netflow records, 350 million SNMP measurements, and 60 million BGP routes across about 300 active sessions; SNMP byte counters were used to scale peering-link Netflow traffic.Source: §5.2 · p. 5, §5.3 · p. 5
5.3 Offload Impact
- On Sep. 19, Apple, Limelight, and Akamai carried 33%, 44%, and 23% of excess update traffic, respectively; Limelight traffic peaked at 438% of its pre-update maximum.On Sep. 20–21, Apple carried about 60% and Limelight about 40% of additional traffic, with no additional Akamai traffic.Source: §5.3 · p. 6, Figure 7 · p. 6
- Apple appeared to use its own CDN first before offloading, and the CDN split changed by day, making traffic distribution difficult to predict from delivery knowledge alone.Apple’s traffic stayed high capacity throughout Sep. 20 while the other CDNs showed diurnal patterns.Source: §5.3 · pp. 5–6
5.4 Overflow Impact
- On Sep. 19, AS D—previously unseen—carried more than 40% of Limelight overflow traffic, and two of its four direct ISP links were entirely saturated at peak times.Limelight stopped using these caches after three days, and the normal traffic pattern returned.Source: §5.4 · p. 6, Figure 8 · p. 6
6 CONCLUSION
The paper characterizes Apple’s self-operated Meta-CDN, including its DNS-based request mapping, cache sites, and use of third-party CDNs. Measurements during a major iOS update show that offload and overflow complicate ISP traffic prediction, with overflow saturating unrelated peering links.
6 CONCLUSION
- Measurements from more than 800 vantage points identified 34 cache sites and analyzed their internal structure using HTTP headers.The Apple Meta-CDN used Akamai, Limelight, and Apple’s own content delivery infrastructure.Source: §6 · p. 6
- During the September 2017 iOS update, Apple offloaded traffic to third-party CDNs in Europe, while overflow fully saturated peering links not expected to be affected.The study found that CDN selection and traffic shares were difficult for an ISP to predict because offload strategies were unknown.Source: §6 · p. 6