Distributing Content Simplifies ISP Traffic Engineering

Abhigyan Sharma† Arun Venkataramani† Ramesh K Sitaraman†?

† University of Massachusetts Amherst ? Akamai Technologies140 Governors DriveAmherst MA 01003

{abhigyan,arun,ramesh}@cs.umass.edu

ABSTRACTSeveral major Internet service providers today also offer con-tent distribution services. The emergence of such “network-CDNs” (NCDNs) is driven both by market forces as well asthe cost of carrying ever-increasing volumes of traffic acrosstheir backbones. An NCDN has the flexibility to determineboth where content is placed and how traffic is routed withinthe network. However NCDNs today continue to treat trafficengineering independently from content placement and re-quest redirection decisions. In this paper, we investigate theinterplay between content distribution strategies and trafficengineering and ask whether or how an NCDN should ad-dress these concerns in a joint manner. Our experimentalanalysis, based on traces from a large content distributionnetwork and real ISP topologies, shows that realistic (i.e.,history-based) joint optimization strategies offer little bene-fit (and often significantly underperform) compared to sim-ple and “unplanned” strategies for routing and placementsuch as InverseCap and LRU. We also find that the simplerstrategies suffice to achieve network cost and user-perceivedlatencies close to those of a joint-optimal strategy with fu-ture knowledge.

Categories and Subject DescriptorsC.2.3 [Network Operations]: Network management; C.2.4[Distributed Systems]: Distributed applications

KeywordsTraffic engineering; Content distribution; Network CDN

1. INTRODUCTIONContent delivery networks (CDNs) today provide a core

service that enterprises use to deliver web content, down-loads, and streaming media to a global audience of end-users. The traditional and somewhat simplified, tripartiteview of content delivery involves three sets of entities as

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SIGMETRICS’13, June 17Ð21, 2013, Pittsburgh, PA, USA.Copyright 2013 ACM 978-1-4503-1900-3/13/06 ...$15.00.

CDN

Content Providers

NetworksNetwork CDN

Figure 1: Network CDNs (NCDNs) allow a tighterintegration of content delivery functionality with theISP’s network operations.

shown in Figure 1. The content providers (e.g., media com-panies, news channels, e-commerce sites, software distribu-tors, enterprise portals, etc.) own the content and wish toprovide a high-quality experience to end-users who accesstheir content. The networks (e.g., telcos such as AT&T,multi-system operators such as Comcast, and ISPs) own theunderlying network infrastructure and are responsible forprovisioning capacity and routing traffic demand. Finally,the CDNs (e.g., Akamai [28], Limelight) optimize contentdelivery to end-users on behalf of the content providers, re-siding as a global, distributed overlay service [13].

Recent powerful trends are reshaping the simplified tri-partite view of content delivery. A primary driver is thetorrid growth of video [27, 11] and downloads traffic on theInternet. For example, a single, popular TV show with 50million viewers, with each viewer watching an HD-qualitystream of 10 Mbps, generates 500 Tbps of network traffic!The increasing migration of traditional media content to theInternet and the consequent challenges of scaling the net-work backbone to accommodate that traffic has necessitatedthe evolution of network CDNs (or NCDNs)1 that verticallyintegrate CDN functionality such as content caching andredirection with traditional network operations [19, 26, 24,8, 36] (refer Figure 1). Another economic driver of NCDNsis the desire of networks to further monetize the “bits” thatflow on their infrastructure and to offer value-added servicesto their own end-user subscribers, e.g., Verizon’s recent of-fering that delivers HBO’s content to FIOS subscribers [35].Two key trends in how networks implement NCDNs [3] aremanaged CDNs where a CDN provider (such as Akamai)deploys their own servers at the network’s PoPs and oper-ates the CDN service on behalf of the network provider [2];and, licensed CDNs where the CDN provider licenses theirsoftware to the network who then deploy and operate theNCDN themselves [1, 10].

1NCDNs are also called Telco CDNs, or Carrier CDNs.

As NCDNs control both the content distribution and thenetwork infrastructure, the costs and objectives of their in-terest are different both from a traditional CDN and a tradi-tional ISP. In particular, an NCDN is in a powerful positionto place content in a manner that “shapes” the traffic de-mand so as to optimize both network cost and user-perceivedlatency. Indeed, several recent works have alluded to thebenefits of such joint optimization strategies in the contextof cooperative or competitive interaction between ISPs andcontent providers [38, 14, 21, 18]. NCDNs today largelytreat the content distribution layer and the traffic engineer-ing layer separately, treating the former as an overlay overthe latter. However, an NCDN is the perfect setting forfielding a joint optimization as both layers are for the firsttime closely alligned in terms of both the business objectivesand the system architecture.

The intriguing prospect of jointly optimizing content de-livery and traffic engineering raises several research ques-tions that form the focus of this paper. How should anNCDN determine content placement, network routing, andrequest redirection decisions so as to optimize network costand user-perceived latency? How much benefit do joint opti-mization strategies yield over simpler strategies as practicedtoday, and does the benefit warrant the added complexity?How do content demand patterns and placement strategiesimpact network cost? How do planned strategies (i.e., us-ing knowledge of recently observed demand patterns or hintsabout anticipated future demands) for placement and rout-ing compare against simpler, unplanned strategies?

Our primary contribution is to empirically analyze theabove questions for realistic content demand workloads andISP topologies. To this end, we collect content requesttraces from Akamai, the world’s largest CDN today. We fo-cus specifically on on-demand video and large-file downloadstraffic as they are two categories that dominate overall CDNtraffic and are significantly influenced by content placementstrategies. Our combined traces consist of a total of 28.2million requests from 7.79 million unique users who down-loaded a total of 1455 Terabytes of content across the USover multiple days. Our main finding based on trace-drivenexperiments using these logs and realistic ISP topologies isthat simple, unplanned strategies for placement, routing, andredirection of NCDN content are better than sophisticatedjoint-optimization approaches. Specifically,

• For NCDN traffic, simple unplanned schemes for place-ment and routing (such as least-recently-used and In-verseCap) yield significantly lower (2.2–17×) networkcost and user-perceived latency than a joint-optimalscheme with knowledge of the previous day’s demand2.

• NCDN traffic demand can be“shaped”by simple place-ment strategies so that traffic engineering, i.e., opti-mizing routes with knowledge of recent traffic matri-ces, hardly improves network cost or user-perceivedlatency over unplanned routing (InverseCap).

• For NCDN traffic, unplanned placement and routing isjust 1%-18% sub-optimal compared to a joint-optimalplacement and routing with perfect knowledge of thenext day’s demand at modest storage ratios (≈ 4).

2We use the term “optimal” when placement or routing isthe solution of an optimization problem, but the solutionmay not have the lowest cost (for reasons detailed in §5.3.1)

PoP

Content serversdeployed at PoPs

Backbone Link

Virtual Origin ServerNetwork

Exit Node

Figure 2: NCDN Architecture

• With a mix of NCDN and transit traffic, traffic engi-neering does lower network cost (consistent with pre-vious studies), but the value of traffic engineering sub-stantially diminishes as the relative volume of NCDNtraffic begins to dominate that of transit traffic.

In the rest of this paper, we first overview the NCDN ar-chitecture highlighting why it changes traditional ISP andCDN concerns (§2). Next, we formalize algorithms thatjointly optimize content placement and routing in an NCDN(§3). We then describe how we collected real CDN traces(§4) and evaluate our algorithms using these traces and realISP topologies (§5). Finally, we present related work (§7)and conclusions (§8).

2. BACKGROUND AND MOTIVATIONA typical NCDN architecture, as shown in Figure 2, re-

sembles the architecture of a global CDN but with someimportant differences. First, the content servers are de-ployed at points-of-presence (PoPs) within a single networkrather than globally across the Internet as the NCDN is pri-marily interested in optimizing content delivery for its owncustomers and end-users. Second, and more importantly,content distribution and network operations are tightly al-ligned, so that a joint optimization of these layers is feasible.In fact, in some cases such as a Licensed CDN, a single en-tity may own and manage both the content servers and theunderlying network. Content providers whose content is de-livered by the NCDN publish their content to origin serversthat they maintain external to the NCDN itself.

Each PoP is associated with a distinct set of end-userswho request content such as web, video, downloads etc. Anend-user’s request is first routed to the content servers atthe PoP to which the end-user is connected. If a contentserver at that PoP has the requested content in their cache,it serves that to the end-user. Otherwise, if the requestedcontent is cached at other PoPs, the content is downloadedfrom a nearby PoP and served to the end-user. If the contentis not cached in any PoP, it is downloaded directly from thecontent provider’s origin servers.

2.1 Why NCDNs Change the GameManaging content distribution as well as the underlying

network makes the costs and objectives of interest to anNCDN different from that of a traditional CDN or a tra-ditional ISP. Figure 3 (top) shows the traditional concernsof content distribution and traffic engineering as addressedby a traditional CDN and a traditional ISP respectively,while Figure 3 (bottom) shows the combined concerns thatan NCDN must address. We explain these in detail below.

Content

Distribution (CDN)

Tra!c Engineering

(Network)

Content

Matrix

Storage

Capacities

Tra!c

Matrix

Link

Capacities

Content

Placement

Request

Redirection

Routing

NCDN Management

(Network CDN)

Content

Matrix

Storage

Capacities

Link

Capacities

Content

Placement

Request

Redirection

Routing

Figure 3: (Top) Traditional formulation with con-tent distribution and traffic engineering optimizedseparately. (Bottom) Our new formulation ofNCDN magamenent as a joint optimization.

2.1.1 Content DistributionA traditional CDN has two key decision components—

content placement and request redirection—that seek to op-timize the response time perceived by end-users and balancethe load across its content servers. Content placement de-cides which objects should be cached at which nodes. Anobject may be stored at multiple nodes in the network or notstored in the network at all and be served from the originserver instead. Request redirection determines which serverstoring a replica of the object is best positioned to serve it.

Content placement schemes can either be planned or un-planned. A planned scheme calculates placement using acontent matrix that specifies the demand for each content ateach location. The content matrix is learned by monitoringa recent history of system-wide requests and possibly includ-ing hints, if any, from content providers about anticipateddemand for some objects. A planned scheme uses a recentcontent matrix to decide on a placement periodically (e.g.,daily) but does not alter its placement in between. In con-trast, an unplanned scheme can continually alter its place-ment potentially even after every single request. A simpleand widely used example of an unplanned placement schemeis LRU, where each server evicts the least-recently-used ob-ject from its cache to make room for new ones.

2.1.2 Traffic EngineeringA key component of ISP network operations is traffic en-

gineering, which seeks to route the traffic demands throughthe backbone network so as to balance the load and mit-igate hotspots. Traffic engineering is commonly viewed asa routing problem that takes as input a traffic matrix, i.e.,the aggregate flow demand between every pair of PoPs ob-served over a recent history, and computes routes so as tominimize a network-wide cost objective. The cost seeks tocapture the severity of load imbalance in the network andcommon objective functions include the maximum link uti-lization (MLU) or a convex function (so as to penalize higherutilization more) of the link utilization aggregated across alllinks in the network [16]. ISPs commonly achieve the com-puted routing either by using shortest-path routing (e.g.,

the widely deployed OSPF protocol [16]) or by explicitlyestablishing virtual circuits (e.g., using MPLS [15]). ISPsperform traffic engineering at most a few times each day,e.g., morning and evening each day [17].

Routing can also be classified as planned or unplannedsimilar in spirit to content placement. Traffic engineeringschemes as explained above are implicitly planned as theyoptimize routing for recently observed demand. To keep theterminology simple, we also classify online traffic engineeringschemes [22, 15] (that are rarely deployed today) as planned.In contrast, unplanned routing schemes are simpler and relyupon statically configured routes [7, 9], e.g., InverseCap isa static shortest-path routing scheme that sets link weightsto the inverse of their capacities; this is a common defaultweight setting for OSPF in commercial routers [17].

2.1.3 NCDN ManagementAs NCDNs own and manage the infrastructure for content

distribution as well as the underlying network, they are in apowerful position to control all three of placement, routing,and redirection (Figure 3). In particular, an NCDN canplace content in a manner that “shapes” the traffic demandsso as to jointly optimize both user-perceived latency as wellas network cost.

To appreciate how placement can shape traffic, considerthe simple example in Figure 4. Node C has an object inits cache that is requested by end-users at nodes A and D.Suppose that one unit of traffic needs to be routed from Cto A and 0.5 units from C to D to satisfy the demand forthat object. The routing that achieves the minimum MLUof 0.5 to serve the demanded object is shown in the figure.Note that the routing that achieves the MLU of 0.5 is notpossible with a simple, unplanned protocol like InverseCapas that would route all the traffic demand from C to Avia B, resulting in an MLU of 1. Thus, a (planned) trafficengineering scheme is necessary to achieve an MLU of 0.5.

On the other hand, NCDNs can shape the traffic demandmatrix by using a judicious placement and redirection strat-egy. Suppose that there is some space left in the contentserver’s cache at node B to accommodate an additional copyof the demanded object. By creating an additional copy ofthe object at B, the traffic demand of A can be satisfiedfrom B and the demand of D from C achieving an MLU of0.125. In this case, judicious content placement decreasedthe MLU by a factor of 4. Even more interestingly, thisbest MLU can be achieved using a simple routing schemelike InverseCap while also improving user-perceived latency(assuming that the latency of link BA is lower than that ofthe two-hop paths from C to A).

The above toy example suggests benefits to jointly opti-mizing placement, routing, and redirection, but raises sev-eral natural questions. How much additional benefit doessuch joint optimization offer compared to treating CDN andISP concerns independently as practiced today? Is the addedcomplexity of joint optimization strategies worth the bene-fit? Which of the three—placement, routing, and redirection—is the most critical to reducing network cost and user-perceivedlatency? How sensitive are these findings to characteristicsof the content workload (e.g., video vs. download traffic)?

3. NCDN MANAGEMENT STRATEGIESTo answer the above questions, we develop an optimiza-

tion model for NCDNs to decide placement, routing, and

Tra�c labeled

with �ow values

0.5

0.5

0.5 11

4

1

8Link labeled

with capacity

A D

CB

Figure 4: A simple NCDN example

Input variables and descriptions

V Set of nodes where each node represents a PoPE Set of edges where each link represents a communica-

tion linko Virtual origin node that hosts all the content in KX Set of exit nodes in VDi Disk capacity at node i ∈ V (in bytes)Ce Capacity of link e ∈ E (in bits/sec)K the set of all content accessed by end-usersSk Size of content k ∈ K.Tik Demand (in bits/sec) at node i ∈ V for content k ∈ K

Decision variables and descriptions

α MLU of the networkzk Binary variable indicating whether one or more copies

of content k is placed in the networkxjk Binary variable indicating whether content k is placed

at node j ∈ V ∪ {o}fij Total traffic from node j to node ifije Traffic from node j to node i crossing link e.tijk Traffic demand at node i ∈ V for content k ∈ K served

from node j ∈ V ∪ {o}

Table 1: List of input and decision variables for theNCDN problem formulation.

redirection so as to optimize network cost or user-perceivedlatency. We formulate the optimization problem as a mixed-integer program (MIP), present hardness and inapproxima-bility results, and discuss approximation heuristics to solveMIPs for realistic problem sizes.

3.1 NCDN ModelTable 1 lists all the model parameters. An NCDN consists

of a set of nodes V where each node represents a PoP in thenetwork. The nodes are connected by a set of directed edgesE that represent the backbone links in the network. The setof content requested by end-users is represented by the setK and the sizes of content are denoted by Sk, k ∈ K. Theprimary resource constraints are the link capacities Ce, e ∈E, and the storage at the nodes Di, i ∈ V . We implicitlyassume that the content servers at the PoPs have adequatecompute resources to serve locally stored content.

A content matrix (CM) specifies the demand for each con-tent at each node. An entry in this matrix, Tik, i ∈ V, k ∈ K,denotes the demand (in bits/second) for content k at nodei. CM is assumed to be measured by the NCDN a prioriover a coarse-grained interval, e.g., the previous day. Theinfrastructure required for this measurement is comparableto what ISPs have in place to monitor traffic matrices today.

Origin servers, owned and maintained by the NCDN’s con-tent providers, initially store all content published by con-tent providers. We model origin servers using a single virtualorigin node o external to the NCDN that can be reached viaa set of exit nodes X ⊂ V in the NCDN (Figure 2). Since we

are not concerned with traffic engineering links outside theNCDN, we model the edges (x, o), for all x ∈ X, as havinginfinite capacity. The virtual origin node o always maintainsa copy of all the requested content. However, a request for acontent is served from the virtual origin node only if no copyof the content is stored at any node i ∈ V . In this case, therequest is assumed to be routed to the virtual origin via theexit node closest to the node where the request was made(in keeping with the commonly practiced early-exit or hotpotato routing policy).

ISP networks carry transit traffic in addition to NCDNtraffic, which can be represented as a transit traffic matrix(TTM). Each entry in the TTM contains the volume of tran-sit traffic between two PoPs in the network.

3.2 Cost FunctionsWe evaluate NCDN-management strategies based on two

cost functions. The first cost function is maximum link uti-lization (or MLU) which measures the effectiveness of trafficengineering in an NCDN. MLU is a widely used networkcost function for traditional TE.

The second cost function models user-perceived latencyand is defined as

∑e∈E Xe, where Xe is the product of traf-

fic on link e and its link latency L(e). The latency of alink L(e) is the sum of a fixed propagation delay and avariable utilization dependent delay. For a unit flow, linklatency is defined as Le(ue) = pe(1 + f(ue)), where pe is thepropagation delay of edge e, ue is its link utilization, andf(u) is a piecewise-linear convex function. This cost func-tion is similar to that used by Fortz and Thorup [16]. Atsmall link utilizations ( < 0.6), link latency is determinedlargely by propagation delay hence f is zero. At higher linkutilizations (0.9 and above) an increase in queuing delayand delay caused by retransmissions significantly increasethe effective link latency. The utilization-dependent delay ismodeled as proportional to propagation delay as the impactof (TCP-like) retransmissions is more on paths with longerlinks. Since Le is convex, a set of linear constraints can bewritten to constraint the value of Xe (as in [16]).

3.3 Optimal Strategy as MIPWe present here a joint optimization strategy for NCDN-

management formulated as a MIP. This formulation takesas input a content matrix, i.e., the demand for each contentat each network point-of-presence (PoP), and computes con-tent placement, request redirection and routing that mini-mizes an NCDN cost function while respecting link capacityand storage constraints. The decision variables for this prob-lem are listed in Table 1. The MIP to minimize an NCDNcost function C (either MLU or latency) is as follows:

minC (1)

subject to∑j∈V

tijk + tiok = Tik, ∀k ∈ K, i ∈ V (2)

∑k∈K

tijk = fij , ∀j ∈ V −X, i ∈ V (3)

∑k∈K

tijk +∑k∈K

δijtiok = fij , ∀j ∈ X, i ∈ V (4)

where δij is 1 if j is the closest exit node to i and 0 otherwise.

Note that δij is not a variable but a constant that is deter-mined by the topology of the network, and hence constraint(4) is linear.

∑p∈P (l)

fijp −∑

q∈Q(l)

fijq =

fij if l = i,

−fij if l = j,

0 otherwise,

∀i, j, l ∈ V (5)

where P (l) and Q(l) respectively denote the set of outgoingand incoming links at node l.∑

i∈V,j∈V

fije ≤ α× Ce, ∀e ∈ E (6)

∑k∈K

xikSk ≤ Di, ∀i ∈ V (7)

xok = 1, ∀k ∈ K (8)∑i∈V

xik ≥ zk, ∀k ∈ K (9)

xik ≤ zk, ∀k ∈ K, i ∈ V (10)

tijk ≤ xjkTik, ∀k ∈ K, i ∈ V, j ∈ V ∪ {o} (11)

tiok ≤ Tik(1− zk), ∀k ∈ K (12)

xjk, zk ∈ {0, 1}, ∀j ∈ V, k ∈ Kfije, tijk, tiok ≥ 0, ∀i, j ∈ V, e ∈ E, k ∈ K

The constraints have the following rationale. Constraint(2) specifies that the total traffic demand at each node foreach content must be satisfied. Constraints (3) and (4) spec-ify that the total traffic from source j to sink i is the sumover all content k of the traffic from j to i for k. Constraint(5) specifies that the volume of a flow coming in must equalthat going out at each node other than the source or thesink. Constraint (6) specifies that the total flow on a link isat most α times capacity. Constraint (7) specifies that thetotal size of all content stored at a node must be less thanits disk capacity. Constraint (8) specifies that all content isplaced at the virtual origin node o. Constraints (9) and (10)specify that at least one copy of content k is placed withinthe network if zk = 1, otherwise zk = 0 and no copies of kare placed at any node. Constraint (11) specifies that theflow from a source to a sink for some content should be zeroif the content is not placed at the source (i.e., when xjk = 0),and the flow should be at most the demand if the contentis placed at the source (i.e., when xjk = 1). Constraint (12)specifies that if some content is placed within the network,the traffic from the origin for that content must be zero.

Updating the content placement itself generates trafficand impacts the link utilization in the network. For easeof exposition, we have deferred a formal description of thecorresponding constraints to our tech report [32]. Finally,a simple extension to this MIP presented in the tech report[32] jointly optimizes routing given a TTM as well a CM. Wehave presented a CM-only formulation here as our findings(in §5) show that a joint optimization of the CM and TTMis not useful for NCDNs.

3.4 Computational HardnessOpt-NCDN is the decision version of the NCDN problem.

The proofs for these theorems are presented in Appendix A.

Theorem 1. Opt-NCDN is NP-Complete even in the spe-cial case where all objects have unit size, and all demands,link capacities, and storage capacities have binary values.

Corollary 1. Opt-NCDN is inapproximable to within aconstant factor unless P = NP.

3.5 Approximation Techniques for MIPAs solving the MIP for very large problem scenarios is

computationally infeasible, we use two approximation tech-niques to tackle such scenarios.

The first is a two-step local search technique. In the firststep, we “relax” the MIP by allowing the integral variablesxjk and zk to take fractional values between 0 and 1. Thisconverts an MIP into an LP that is more easily solvable.Note also that the optimal solution of the relaxed LP is alower bound on the optimal solution of the MIP. However,the LP solution may contain fractional placement of someof the content with the corresponding xjk variables set tofractional values between 0 and 1. However, in our exper-iments only about 20% of the variables in the optimal LPsolution were set to fractional values between 0 or 1, and therest took integral values of 0 or 1. In the second step, wesearch for a valid solution for the MIP in the local vicinityof the LP solution by substituting the values for variablesthat were set to 0 or 1 in the LP solution, and re-solvingthe MIP for the remaining variables. Since the number ofinteger variables in the second MIP is much smaller, it canbe solved more efficiently than the original MIP.

The second approximation technique reduces the numberof unique content in the optimization problem using twostrategies. First, we discard the tail of unpopular contentprior to optimization. The discarded portion accounts foronly 1% of all requests, but reduces the number of contentby 50% or more in our traces. Second, we sample 25% of thecontent from the trace and, in our experiments, select traceentries corresponding only to the sampled content. Theseapproximations reduce the number of content from tens ofthousands to under 5000. An MIP of this size can be solvedusing local search in an hour by a standard LP solver [20] forthe ISP topologies in our experiments.To check for any un-toward bias introduced by the sampling, we also performeda small number of experiments with the complete trace andverified that our findings remain qualitatively unchanged.

4. AKAMAI CDN TRACESTo conduct a realistic simulation of end-users accessing

content on an NCDN, we collected extensive traces of videoand download traffic from Akamai as described below.

Video traces. Videos are the primary source of trafficon a CDN and are growing at a rapid rate [27, 11]. Ourvideo trace consists of actual end-users accessing on-demandvideos on the Akamai network over multiple days. To makethe traces as representative as possible, we chose contentproviders with a whole range of business models, includingmajor television networks, news outlets, and movie portals.The videos in our traces include a range of video types fromshort-duration video (less than 10 mins) such as news clipsto longer duration (30 min to 120 min) entertainment videosrepresenting TV shows and movies. In all, our anonymizedtraces represent a nontrivial fraction of the overall trafficon Akamai’s media network and accounted for a total of27 million playbacks of over 85000 videos, 738 TBytes oftraffic, served to 6.59 million unique end-users around the

0

0.2

0.4

0.6

0.8

1

3 7 11

Fra

ctio

n o

f R

eq

ue

sts

Day

News

0

0.2

0.4

0.6

0.8

1

3 4 5 6

Fra

ctio

n o

f R

eq

ue

sts

Day

Entertainment

0

0.2

0.4

0.6

0.8

1

3 8 13 18

Fra

ctio

n o

f R

eq

ue

sts

Day

Downloads

New ContentRequests Fraction

Figure 5: News and entertainment have a significant fraction of requests for new content on all days. Down-loads has a small fraction of requests for new content on all days, except one.

US. Since we only had US-based network topologies withaccurate link capacity information, we restricted ourselvesto US-based traffic.

We collect two sets of anonymized video traces called newstrace and entertainment trace respectively. The news tracewas collected from a leading news outlet for an 11-day pe-riod in Sept 2011, and consists mostly of news video clips,but also includes a small fraction of news TV shows. Theentertainment trace was collected for a 6 day period in Jan-uary 2012, and includes a variety of videos including TVshows, clips of TV shows, movies and movie trailers fromthree major content providers.

The trace collection mechanism utilized a plugin embed-ded in the media player that is capable of reporting (anonymized)video playback information. Our traces include a single logentry for each playback and provides time of access, userid, the location of the user (unique id, city, state, country,latitude, and longitude), the url of the content, the contentprovider, the total length of the video (in time and bytes),the number of bytes actually downloaded, the playback du-ration, and the average bitrate over the playback session.

Downloads traces. Downloads of large files over HTTPis also a large large contributor of traffic in a CDN. Theseinclude software and security updates, e.g., Microsoft’s Win-dows or Symantec’s security updates, as well as music, books,movies, etc.. The large file downloads at Akamai typicallyuse a client-side software called the download manager [28].We collect extensive and anonymized access data reportedfrom the download manager using Akamai’s NetSession in-terface [4] for a large fraction of content providers for a pe-riod of a month (December 2010). Our traces represent anontrivial fraction of the overall US-based traffic on Aka-mai’s downloads network and accounted for a total of 1.2million downloads, 717 TBytes of traffic, served to 0.62 mil-lion unique end-users around the US. Our traces providea single log entry for each download and provide time ofaccess, user id, location of the user (city, state, country,latitude, and longitude), the url identifier of the content,content provider, bytes downloaded, and file size.

Figure 5 shows the fraction of requests for new contentpublished each day relative to the previous day for news,entertainment, and downloads traces. The news trace hasup to 63% requests due to new content because the latestnews clips generated each day are the most popular videoson the website. The entertainment trace also has up to 31%requests each day due to new content such as new episodesof TV shows, and the previews of upcoming TV shows. Thedownloads trace has only 2-3% requests due to new contenton a typical day. However, on the 9th day of the trace majorsoftware updates were released, which were downloaded onthe same day by a large number of users. Hence, nearly 20%

requests on that day were for new content. The fraction ofrequests for new content impacts the performance of plannedplacement strategies as we show §5.

5. EXPERIMENTAL EVALUATIONWe conduct trace-driven experiments to compare differ-

ent NCDN-management strategies. Our high-level goal is toidentify a simple strategy that performs well for a variety ofworkloads. In addition, we seek to assess the relative valueof optimizing content placement versus routing; the valueof being planned versus being unplanned and the value offuture knowledge about demand.

5.1 Trace-driven Experimental MethodologyTo realistically simulate end-users accessing content on

an NCDN, we combine the CDN traces (in §4) with ISPtopologies as follows. We map each content request entryin the Akamai trace to the geographically closest PoP inthe ISP topology in the experiment (irrespective of the realISP that originated the request). Each PoP has a contentserver as shown in Figure 2, and the request is served locally,redirected to the nearest (by hop-count) PoP with a copy,or to the origin as needed.

ISP topologies. We experimented with network topol-ogy maps from two US-based ISPs. First is the actual ISPtopology obtained from a large tier-1 ISP in the US (referredto as US-ISP). Second is the Abilene ISP’s topology [33].

MLU computation. We compute the traffic that flowthrough each link periodically. To serve a requested pieceof content from a PoP s to t, we update the traffic inducedalong all edges on the path(s) from s to t as determined bythe routing protocol using the bytes-downloaded informa-tion in the trace. To compute the MLU, we partition simu-lation time into 5-minute intervals and compute the averageutilization of each link in each 5-minute interval. We discardthe values of the first day of the trace in order to warm upthe caches, as we are interested in steady-state behavior. Wethen compute our primary metric, which is the 99-percentileMLU, as the 99th percentile of the link utilization over alllinks and all 5-minute time periods. We use 99-percentileinstead of the maximum as the former is good proxy for thelatter but with less experimental noise. Finally, for ease ofvisualization, we scale the 99-percentile MLU values in allgraphs so that the maximum 99-percentile MLU across allschemes in each graph is equal to 1. We call this scaled MLUthe normalized MLU. Note that only the relative ratios of theMLUs for the different schemes matter and scaling up theMLU uniformly across all schemes is equivalent to uniformlyscaling down the network resources or uniformly scaling upthe traffic in the CDN traces.

Latency cost computation. Our latency cost metric,

which models user-perceived latencies, is a sum of the la-tency on ISP backbone links and the the latency from userto its nearest PoP. Traffic served from origin incurs an ad-ditional latency from origin to the exit locations in the net-work. We assume origin servers to be located close to exitlocations so that latency from exit locations to origin serversis a small fraction of the overall end user latency. The la-tency cost of a link e for a interval of a second when traffic(in bits/sec) on link e is Ve and link utilization is ue, is calcu-lated as Ve×Le(ue), where Le is the latency function definedin §3. The aggregate latency cost of a link is calculated bysumming the latency costs for all 1 sec intervals during theexperiment (excluding the first day). The user-to-nearestPoP latency cost is calculated by summing the traffic (inbits) requested by a user times the propagation delay to itsnearest PoP for all users.

Storage. We assume that storage is provisioned uni-formly across PoPs except in §5.6 where we analyze het-erogenous storage distributions. We repeat each simulationwith different levels of provisioned storage. Since the appro-priate amount of storage depends on the size of the workingset of the content being served, we use as a metric of storagethe storage ratio, or the ratio of total storage at all PoPs inthe network to the average storage footprint of all contentaccessed in a day for the trace. The total storage across allnodes for a storage ratio of 1 is 228 GB, 250 GB, and 895GB for news, entertainment and downloads respectively.

5.2 Schemes EvaluatedEach evaluated scheme has a content placement compo-

nent and a routing component.InvCap-LRU uses LRU as the cache replacement strategy

and InverseCap (with ECMP) as the routing strategy. Inver-seCap is a static, shortest-path routing scheme where linkweights are set to the inverse of the link capacity. Thisscheme requires no information of either the content de-mand or the traffic matrix. If content is available at multiplePoPs, we choose the PoP with least hop count distance whilebreaking ties randomly among PoPs with same hop countdistance.

We added a straightforward optimization to LRU where ifa user terminates the request before 10% of the video (file)is viewed (downloaded), the content is not cached (and therest of the file is not fetched); otherwise the entire file isdownloaded and cached. This optimization is used sincewe observe in our traces that a user watching a video veryoften stops watching it after watching the initial period. Asimilar phenomenon is observed for large file downloads, butless frequently than video.

OptR-LRU uses an unplanned placement, LRU, but ituses an planned, optimized routing that is updated everythree hours. The routing is computed by solving a multi-commodity flow problem identical to the traditional traf-fic engineering problem [16]. We assume that the NCDNmeasures the traffic matrix over the preceding three hoursand computes routes that optimize the MLU for that ma-trix. The matrix incorporates the effect of the unplannedplacement and the implicit assumption is that the contentdemand and unplanned placement result in a traffic matrixthat does not change dramatically from one monitoring in-terval to the next—an assumption that also underlies trafficengineering as practiced by ISPs today.

OptRP computes a joint optimization of placement and

0%

25%

50%

75%

100%

OptRP InvCap-LRU OptRP-Future

Re

qu

ests

(%

) Local Cache

Other NetworkCaches

Origin

(a) News, Abilene

0%

25%

50%

75%

100%

OptRP InvCap-LRU OptRP-Future

Re

qu

ests

(%

) Local Cache

Other NetworkCaches

Origin

(b) Entertainment, Abilene

Figure 7: [Videos, Abilene] OptRP serves 50% and21% of news and entertainment requests respec-tively from the origin. InvCap-LRU and OptRP-Futureserve at most 2% from the origin.

routing once a day based on the previous day’s content ma-trix using the MIP formulation of §3.3. OptRP-Future hasoracular knowledge of the content matrix for the next dayand uses it to calculate a joint optimization of placement,redirection and routing. OptRP and OptRP-Future are iden-tical in all respects except that the former uses the contentmatrix of the past day while the latter has perfect futureknowledge. These two schemes help us understand the valueof future knowledge. In practice, it may be possible for anNCDN to obtain partial future knowledge placing it some-where between the two extremes. For instance, an NCDN islikely to be informed beforehand of a major software releasethe next day (e.g., new version of the Windows) but maynot be able to anticipate a viral video that suddenly gets“hot”.

To determine the value of optimizing routing alone, westudy the InvCap-OptP-Future scheme. This is a variant ofOptRP-Future where InverseCap routing is used and contentplacement is optimized, rather than jointly optimizing both.This scheme is computed using the MIP formulation in §3.3but with an additional constraint modification that ensuresthat InvCap routing is implemented.

We add a suffix -L to the names of a scheme if it is opti-mizing for latency cost instead of MLU, e.g. OptRP-L.

For all schemes that generate a new placement each day,we implement the new placement during the low-traffic pe-riod from 4 AM to 7 AM EST. This ensures that the traf-fic generated due to changing the content placement occurswhen the links are underutilized. For these schemes, therouting is updated each day at 7 AM EST once the place-ment update is finished.

5.3 Comparison of Network Cost

5.3.1 Analysis of Video & Downloads TrafficFigure 6 shows the results for the news, entertainment

and downloads traces on Abilene and US-ISP. Our first ob-servation is that a realistic planned placement and routingscheme, OptRP, performs significantly worse than a com-pletely unplanned scheme, InvCap-LRU. OptRP has 2.2× to

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4

Norm

aliz

ed M

LU

Storage Ratio

OptRPInvCap-LRU

OptRP-Future

(a) News, US-ISP

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4

Norm

aliz

ed M

LU

Storage Ratio

OptRPInvCap-LRU

OptRP-Future

(b) Entertainment, US-ISP

0

0.2

0.4

0.6

0.8

1

0 2 4 6

Norm

aliz

ed M

LU

Storage Ratio

OptRPInvCap-LRU

OptRP-Future

(c) Downloads, US-ISP

0

0.2

0.4

0.6

0.8

1

0 0.5 1 1.5 2

Norm

aliz

ed M

LU

Storage Ratio

OptRPInvCap-LRU

OptRP-Future

(d) News, Abilene

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4

Norm

aliz

ed M

LU

Storage Ratio

OptRPInvCap-LRU

OptRP-Future

(e) Entertainment, Abilene

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4

Norm

aliz

ed M

LU

Storage Ratio

OptRPInvCap-LRU

OptRP-Future

(f) Downloads, Abilene

Figure 6: Planned OptRP performs much worse than unplanned InvCap-LRU. OptRP-Future performs moderatelybetter than InvCap-LRU primarily at small storage ratios.

0.2

0.4

0.6

0.8

5 10 15 20

Time (Day)

MLU

OptRPOptRP-Future

Figure 8: [Downloads, US-ISP] OptRP incurs a veryhigh MLU on one “peak load” day.

17× higher MLU than InvCap-LRU even at the maximumstorage ratio in each graph. OptRP has a high MLU be-cause it optimizes routing and placement based on the pre-vious day’s content demand while a significant fraction ofrequests are for new content not accessed the previous day(see Figure 5). Due to new content, the incoming traffic fromorigin servers is significant, so the utilization of links nearthe exit nodes connecting to the origin servers is extremelyhigh.

The fraction of requests served from the origin is muchhigher for OptRP compared to InvCap-LRU and OptRP-Futureon the news and the entertainment traces. Figure 7 showsthat OptRP serves 50% and 21% of requests from the ori-gin for news and entertainment respectively. In comparison,InvCap-LRU and OptRP-Future serve less than 2% of requestsfrom the origin. Therefore, OptRP has a much higher MLUthan both InvCap-LRU and OptRP-Future on the two traces.

The downloads trace differs from other traces in that, ex-cept for one day, the traffic is quite predictable based on theprevious day’s history. This is reflected in the performanceof OptRP that performs nearly the same as OptRP-Future on

-10

-5

0

5

10

Ma

x M

LU

re

du

ctio

n (

%)

Abilene US-ISP

News

Entertainment

Downloads

(a) MLU reduction with OptR-LRU compared toInvCap-LRU

0

5

10

15

Ma

x M

LU

re

du

ctio

n (

%)

Abilene US-ISP

News

Entertainment

Downloads

(b) MLU reduction with OptRP-Future compared toInvCap-OptP-Future

Figure 9: [All traces] Optimizing routing yields littleimprovement to MLU of either InvCap-LRU or InvCap-OptP-Future

all days except the ninth day of the trace (see Figure 8). Thesurge in MLU for OptRP on the ninth day is because nearly20% of requests on this day is for new content consisting ofhighly popular software update releases (see Figure 5). Thesurge in MLU on this one day is mainly responsible for thepoor performance of OptRP on the downloads trace.

Next, we observe that InvCap-LRU does underperform com-pared to OptRP-Future that has knowledge of future contentdemand. However, InvCap-LRU improves with respect toOptRP-Future as the storage ratio increases. The maximumdifference between the two schemes is for the experiment

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5

Storage Ratio

No

rma

lize

d M

LU

InvCap-LRU

InvCap-LRU-Chunk

OptRP-Future

OptRP-Future-Chunk

Figure 10: [Entertainment, US-ISP] Content chunking helpsbridge the gap between InvCap-LRU and OptRP-Future.

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4

Storage Ratio

No

rma

lize

d M

LU OptRP-Hybrid

InvCap-LRU

Figure 11: [Entertainment, Abi-lene] Hybrid placement schemesperform at best as well as InvCap-LRU.

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5

Storage Ratio

No

rma

lize

d M

LU

InvCap-LRU

OptRP-2/day

OptRP-4/day

OptRP-8/day

Figure 12: [Entertainment, US-ISP] OptRP does not outperformInvCap-LRU despite engineering 8times a day.

with entertainment trace on US-ISP topology. In this case,at a storage ratio of 1, InvCap-LRU has twice the MLU ofthe OptRP-Future scheme; the difference reduces to 1.6× ata storage ratio of 4. This shows that when storage is scarce,planned placement with future knowledge can significantlyhelp by using knowledge of the global demand to maximizethe utility of the storage. However, if storage is plentiful,the relative advantage of OptRP-Future is smaller. An im-portant implication of our results is that an NCDN shouldattempt to do planned placement only if the future demandcan be accurately known or estimated. Otherwise, a simplerunplanned scheme such as LRU suffices.

How are the above conclusions impacted if InvCap-LRUwere to optimize routing or OptRP-Future were to use In-verseCap routing? To answer this question, we analyzethe maximum reduction in MLU by using OptR-LRU overInvCap-LRU across all storage ratios in Figure 9. We sim-ilarly compare OptRP-Future and InvCap-OptP-Future. Wefind that OptR-LRU improves the MLU over InvCap-LRU byat most 10% across all traces suggesting that optimizingrouting is of little value for an unplanned placement scheme.OptRP-Future reduces the network cost by at most 13% com-pared to InvCap-OptP-Future. As we consider OptRP-Futureto be the “ideal” scheme with full future knowledge, theseresults show that the best MLU can be achieved by optimiz-ing content placement alone; optimizing routing adds littleadditional value.

Why do InvCap-LRU and OptR-LRU have nearly the samenetwork costs? While LRU does greatly reduce traffic dueto a high percentage of cache hits, but this is not enough toexplain why InvCap achieves nearly the same MLU as opti-mized routing for the residual traffic, however small. Trafficengineering gives little additional value either because trafficmatrices are unpredictable and/or because the NCDN traf-fic matrices and ISP topologies that we consider do not givemuch scope for an optimized routing to reduce the MLUover InverseCap routing.

Somewhat counterintuitively, the MLU sometimes increaseswith a higher storage ratio for the OptRP scheme. There arethree reasons that explain this. First, the optimization for-mulation optimizes for the content matrix assuming that thedemand is uniformly spread across the entire day, howeverthe requests may actually arrive in a bursty manner. Soit may be sub-optimal compared to a scheme that is ex-plicitly optimized for a known sequence of requests. Sec-ond, the optimization formulation optimizes the MLU forthe “smoothed” matrix, but the set of objects placed by theoptimal strategy with more storage may not necessarily be

a superset of the objects placed by the strategy with lesserstorage at any given PoP. Third, and most importantly, theactual content matrix for the next day may differ signifi-cantly from that of the previous day. All of these reasonsmake the so-called“optimal”OptRP strategy suboptimal andin combination are responsible for the nonmonotonicity ob-served in the experiments.

5.3.2 Content ChunkingContent chunking is widely used today to improve con-

tent delivery and common protocols such as HTTP [30] andApple HLS [5] support content chunking. This experimentanalyzes the effect of content chunking on our findings. Inthese experiments, we split videos into chunks of 5 minuteduration. The size of a video chunk depends on the video bi-trate. For the downloads trace, we split content into chunksof size 50 MB.

Our results show that although chunking improves per-formance of both InvCap-LRU and OptRP-Future, it signif-icantly improves the performance of InvCap-LRU relativeto OptRP-Future (see Figure 10). Due to chunking, themaximum difference between the MLU of InvCap-LRU andOptRP-Future reduces from 2.5× to 1.4×. At the maximumstorage ratio, InvCap-LRU is at most 18% worse compared toOptRP-Future. Our experiments on other traces and topolo-gies (omitted for brevity) show that InvCap-LRU has at most4% higher network cost than OptRP-Future at the maximumstorage ratio. An exception is the news trace, where chunk-ing makes a small difference as more than 95% content is ofduration less than our chunk size. Hence, chunking strength-ens our conclusion that InvCap-LRU achieves close to the bestpossible network cost for an NCDN. Even with chunking,OptRP has up to 7× higher MLU compared to InvCap-LRU(not shown in Figure 10). This is because chunking does nothelp OptRP’s primary problem of not being able to adapt ef-fectively to new content, so it continues to incur a high cost.

5.3.3 Alternative Planned SchemesThe experiments so far suggest that a planned scheme that

engineers placement and routing once a day based on theprevious day’s demand performs poorly compared to an un-planned scheme, InvCap-LRU. Hence, in this section, we eval-uate the performance of two alternative planned schemes.

First, we evaluate a hybrid placement scheme, which splitsthe storage at each node into two parts - one for a plannedplacement based on the previous day’s content demand (80%of storage) and the other for placing the content in a un-planned LRU manner (20% of storage). We find that InvCap-

0

2e+07

4e+07

6e+07

8e+07

0 1 2 3 4

Late

ncy

Cos

t

Storage Ratio

OptRP-LInvCap-LRU

OptRP-Future-L

(a) News, US-ISP

0

3e+06

6e+06

9e+06

1.2e+07

1.5e+07

0 1 2 3 4

Late

ncy

Cos

t

Storage Ratio

OptRP-LInvCap-LRU

OptRP-Future-L

(b) Entertainment, US-ISP

0

2e+06

4e+06

6e+06

8e+06

0 2 4 6

Late

ncy

Cos

t

Storage Ratio

OptRP-LInvCap-LRU

OptRP-Future-L

(c) Downloads, US-ISP

Figure 13: A realistic planned scheme, OptRP-L causes excessively high latency costs in some cases. InvCap-LRUachieves latency costs close to ideal planned scheme, OptRP-Future-L, at higher storage ratios.

LRU performs either as well or better than the hybrid scheme.Assigning a greater fraction of storage to unplanned place-ment does not change the above conclusions (graph omittedfor brevity). Of course, a carefully designed hybrid schemeby definition should perform at least as well as the un-planned and planned schemes, both of which are extremecases of a hybrid strategy. However, we were unable to de-sign simple hybrid strategies that consistently outperformedfully unplanned placement and routing.

Next, we analyze the performance of planned schemes thatengineer placement and routing multiple times each day atequal intervals - twice/day, 4 times/day, and 8 times/day. Inall cases, we engineer using the content demand in the past24 hours. As Figure 12 shows, OptRP needs to engineer8 times/day to match the performance of the InvCap-LRUscheme. In all other cases, InvCap-LRU performs better. Infact, the experiment shown here represents the best case forOptRP. Typically, OptRP performs worse even when engi-neering is done 8 times/day, e.g., on the news trace, we findOptRP incurs up to 4.5× higher MLU compared to InvCap-LRU even on engineering 8 times/day.

Executing a planned placement requires considerable effort—measuring content matrix, solving a computationally inten-sive optimization, and moving content to new locations.Further, a planned placement needs to be executed 8 timesa day (or possibly more) even to match the cost achieved byan unplanned strategy. Our position is that NCDNs are bet-ter served by opting for a much simpler unplanned strategyand provisioning more storage, in which case, an unplannedstrategy already obtains a network cost close to the best aplanned strategy can possibly achieve.

5.4 Comparison of Latency CostWe compare InvCap-LRU scheme, which is a completely

unplanned scheme, against OptRP-L and OptRP-Future-L,which optimize latency cost based on previous day’s contentmatrix and based on next day’s content matrix respectively.

We experiment with ISP topologies in which links arescaled down uniformly. We needed to scale down the linksas our traces did not generate enough traffic to fill even 5%of the capacity of the links during the experiment; ISP net-works are unlikely to operate at such small link utilizations.The network topology is scaled such that the 99-percentileMLU for results is 75% link utilization for the InvCap-LRUscheme. This ensures that network has sufficient capacity tosupport content demand at all storage ratios and networklinks are not heavily under-utilized.

We present the results of our comparison on the US-ISPtopology in Figure 13. Experiments on the Abilene topol-

ogy show qualitatively similar conclusions (graph omittedfor brevity). We find that on the news and entertainmenttraces, OptRP-L scheme results in an order of magnitudehigher latency costs. OptRP-L scheme is similar to OptRPscheme except it optimizes latency instead of network cost.Like the OptRP scheme, OptRP-L is unable to predict thepopularity of new content resulting in high volume of trafficfrom origin servers and high link utilization values. OptRP-Leither exceeds link capacities or operates close to link capac-ity for some links which results in very high latencies.

The latency cost of InvCap-LRU relative to OptRP-Future-L improves with an increase in storage ratio. At the smalleststorage ratio, InvCap-LRU has 70-110% higher latency costthan OptRP-Future-L. The difference reduces to 14-34% atthe maximum storage ratio. Higher storage ratio translateto higher cache hit rates, which reduces propagation delayof transfers and lowers link utilizations. Both these factorscontribute to a smaller latency cost for InvCap-LRU. Thisfinding shows that NCDNs can achieve close to best latencycosts with an unplanned scheme InvCap-LRU and provision-ing moderate amounts of storage.

The performance of OptRP-L on the downloads trace ismuch closer to OptRP-Future-L than on the other two traces.Unlike other traces, content popularity is highly predictableon the downloads trace based on yesterday’s demand, exceptfor a day on which multiple new software releases were done.On all days except one, OptRP-L has nearly optimal latencycost and it incurs a higher latency cost on one day of thetrace. As a result, OptRP-L’s aggregate latency cost summedover all days is only moderately higher than that of OptRP-Future-L.

5.5 Effect of NCDN Traffic on Network CostThis experiment, unlike previous experiments, considers a

network consisting of both ISP and NCDN traffic. Our goalis to evaluate how network costs change as the fraction ofNCDN traffic increases in the network. Second, we seek toexamine the benefit of optimizing routing over an unplannedrouting scheme, InverseCap. To this end, we compare theperformance of InvCap-LRU and OptR-LRU schemes. Thelatter scheme optimizes routing for the combined traffic ma-trix due to NCDN traffic and ISP transit traffic. In order toestimate the best gains achievable with an optimized rout-ing, we provide to the OptR-LRU scheme knowledge of fu-ture ISP traffic matrices. OptR-LRU cannot be provided theknowledge of future NCDN traffic matrices because NCDNtraffic matrices can only be measured from experiment itselfand we do not know them beforehand. We optimize rout-

0

0.2

0.4

0.6

0.8

1

0 25 50 75 100

Nor

mal

ized

MLU

NCDN Traffic %

InvCap-LRUOptR-LRU

Figure 14: [News, US-ISP] Network costs at varyingfractions of NCDN traffic in an ISP network.

ing once a day in this experiment. Varying the frequency ofrouting update did not improve OptR-LRU’s performance.

We experiment with hourly transit traffic matrices span-ning 7 days from the same Tier-1 ISP — US-ISP. Thesematrices were collected in February, 2005. Since ISP traf-fic volumes are much higher than NCDN traffic volumes, atfirst, we performed this experiment by scaling down the ISPtraffic matrices, so that ISP and NCDN traffic have com-parable volumes. Of the total NCDN traffic, less than 10%reaches the backbone links, rest is served locally by PoPs.For equal volumes of NCDN and ISP traffic we expected theMLU of a network with ISP traffic only to be much higherthan MLU for the network with only NCDN traffic. Our ex-periment showed that MLU for ISP traffic and NCDN trafficare nearly the same.

We found that this was because the NCDN traffic showedhighly variable link utilization even over the course of a fewminutes: the maximum link utilization differed by up to 3×in the course of 15 minutes. The hourly ISP traffic matrixthat we experimented with retained the same, smoothed uti-lization level for an hour. As a result, 99-percentile MLU’sfor NCDN traffic are the same as that for ISP even thoughits aggregate backbone traffic was much lesser.

To make the variability of NCDN traffic comparable toISP traffic, we scaled up the volume of NCDN traffic. Thescaling is done by introducing new content similar to a ran-domly chosen content in the original trace. Each new con-tent is of the same size, and same video bit rate as the origi-nal content. All requests for the new content are made fromthe same locations, at approximately the same times (withinan 1-hour window of the request of the original content), andare of the same durations as the requests for the originalcontent. Our scaling preserves the popularity distributionof objects and the geographic and temporal distribution ofrequests. We scaled our trace to the maximum level so asto not exceed the memory available (8 GB) in our machine.

We present the results of our experiments on the newstrace in Figure 14. We vary the fraction of NCDN to ISPtraffic, and report MLUs normalized by the total volume ofISP and NCDN traffic. Our results are not independent ofthe scale of simulations: a larger or a smaller scaling of CDNtrace may give quantitatively different conclusions. Hence,we only make qualitative conclusions from this experiment.First, we find that as the fraction of NCDN traffic increases,MLU decreases for both schemes. This is intuitive since alarge fraction of NCDN traffic is served from caches locatedat PoPs. Second, as NCDN traffic increases optimizing rout-ing (OptR-LRU) gives lesser benefits compared to InverseCaprouting. In a network dominated by NCDN traffic, optimiz-ing routing gives almost no benefits over InvCap-LRU. We

find these results to be consistent with our earlier experi-ments with NCDN traffic only.

5.6 Other Results and ImplicationsWe summarize our main conclusions from the rest of our

experiments here and refer the reader to our tech report [32]for a complete description of these experiments:

Link-utilization aware redirection: We evaluate a re-quest redirection strategy for InvCap-LRU that periodicallymeasures link utilizations in the network and prefers lessloaded paths while redirecting requests. Our evaluationshows that such a redirection gives small benefits in terms ofnetwork cost (7%−13%) and gives almost no benefits on la-tency costs. This implies that sophisticated network-awareredirection strategies may be of little value for an NCDN.

Request redirection to neighbors: If each PoP redi-rects requests only to its one-hop neighbor PoPs before redi-recting to the origin, InvCap-LRU incurs only a moderate(6%-27%) increase in the MLU. However, if a PoP redirectsto no other PoPs but redirects only to the origin, the MLUfor InvCap-LRU increases significantly (25%-100%). Thus,request redirection to other PoPs helps reduce network cost,but most of this reduction can be had by redirecting only toneighboring PoPs.

Heterogenous storage: Heterogenous storage at PoPs(storage proportional to the number of requests at a PoPin a trace, and other simple heuristics) increases the MLUcompared to homogenous storage for both InvCap-LRU andOptRP-Future, and makes InvCap-LRU more sub-optimal com-pared to OptRP-Future. This leads us to conclude that ourresults above with homogeneous storage are more relevantto practical settings.

Number of caches: If caches are deployed on all PoPs,MLU is significantly lower compared to scenarios when cachesare deployed only at a fraction of PoPs; the total storageacross PoPs is same in all scenarios. This suggests thatNCDNs should deploy caches at all PoPs to minimize MLU.

OptR-LRU parameters: Whether OptR-LRU updates rout-ing at faster timescales (every 15 minutes, or 30 minutes) orslower timescales (6 hours, or 24 hours) than the default up-date interval of 3 hours, its performance is nearly the same.Further, whether OptR-LRU optimizes routing using traf-fic matrix measured over the immediately preceding threehours (default) or using traffic matrices measured the pre-vious day, its network cost remains nearly unchanged. Thisreinforces our finding that optimizing routing gives minimalimprovement over InvCap-LRU.

Number of exit nodes: When the number of networkexit nodes is increased to five or decreased to one, our find-ings in §5.3.1 remain qualitatively unchanged.

Link failures: The worst-case network cost across allsingle link failures for InvCap-LRU as well as OptRP-Futureis approximately twice compared to their network costs dur-ing a failure-free scenario. Comparing the failure-free sce-nario and link failure scenarios, the relative sub-optimalityof InvCap-LRU with respect to OptRP-Future remains thesame at small storage ratios but reduces at higher ratios.

6. LIMITATIONS AND FUTURE WORKOur experimental methodology suffers from some short-

comings. First, we assume that servers deployed at eachPoP have enough resources to serve users requests for locallycached content. In cases when server resources are inade-

quate, e.g., due to flash crowds, a simple redirection strat-egy, e.g., redirection to the closest hop-count server used byInvCap-LRU, may result in poor user-perceived performance.In practice, NCDNs should adopt a redirection strategy thattakes server load into account to handle variability of userdemands. Second, we measure latency using a utility-basedcost function that can be efficiently computed using flow-level simulations. An evaluation of end-user perceived met-rics, e.g., TCP throughput, would be more convincing, butrequires a measurement-based evaluation or a packet-levelsimulation. A measurement-based evaluation requires net-work and server infrastructure similar to an NCDN, which isbeyond our resources. Even packet-level simulations becomeextremely time consuming at the scale of an ISP network,which we observed in an earlier work [31]. Third, the latencycomparison is done for large, static objects and is not gen-eralizable to dynamic content and small objects. We deferaddressing these concerns to future work.

Another open question is whether our conclusions are gen-eralizable for other topologies and workloads. For instance,our preliminary analysis with a synthetic workload trace (in-cluded in [32]) suggests that the InvCap-LRU scheme may notgive the close to optimal costs in all scenarios. An evaluationof relative performance of schemes for general topologies andworkloads would be considered in our future work.

7. RELATED WORKTraffic engineering and content distribution have both seen

an enormous body of work over more than a decade. To ourknowledge, our work is the first to consider the NCDN prob-lem, wherein a single entity seeks to address both concerns,and empirically evaluate different placement, routing, andredirection strategies.

Joint optimization: Recent work has explored the jointoptimization of traffic engineering and “content distribu-tion”, where the latter term refers to the server selectionproblem. P4P (Xie et al. [38]) shows that P2P applica-tions can improve their performance and ISPs can reducethe MLU and interdomain costs, if P2P applications adapttheir behavior based on hints supplied by ISPs. Jiang et al.[21] and DiPalantino et al. [14] both study the value of jointoptimization of traffic engineering and content distributionversus independent optimization of each. CaTE (Frank atal. [18]), like P4P, shows that a joint optimization can helpboth ISPs and content providers improve their performance.Valancius et al. [34] propose a system which helps online ser-vice providers choose the best server replica for each clientconsidering multiple server replicas and multiple networkpaths to each replica. Further, they quantify the benefitof this “joint routing” approach over “content routing”, i.e.,choosing best replica with only a single path to each replica,and over “network routing”, i.e., choosing best path to anunreplicated server among multiple paths. Xu et al. [39]study a similar problem. These works equate content dis-tribution to server selection (or request redirection in ourparlance), while the NCDN problem additionally considerscontent placement itself as a degree of freedom. We findthat the freedom to place content is powerful enough thateven unplanned placement and routing strategies suffice toachieve close to best latency and network costs for NCDNs,making joint optimization of content distribution and trafficengineering unnecessary.

Placement optimization: In the context of CDNs, many

variants of content or service placement problems have beenstudied [29, 25, 12, 23]. A recent work is that of Applegateet al. [6], who study the content placement problem for aVoD system that seeks to minimize the aggregate networkbandwidth consumed. However, they assume a fixed routingin the network, while one of our contributions is to assessthe relative importance of optimizing routing and optimizingplacement in an NCDN.

Furthermore, they find that an optimized, planned place-ment with a small local cache (similar to our “hybrid” strat-egy in §5.3.3) outperforms LRU. In contrast, our experi-ments suggest otherwise. There are three explanations forthis disparity. First, their workload seems to be predictableeven at weekly time scales, whereas the Akamai CDN tracesthat we use show significant daily churn. Second, theirscheme has some benefit of future knowledge and is hencesomewhat comparable to our OptRP-Future. For a largeNCDN, obtaining knowledge about future demand may notbe practical for all types of content, e.g., breakout newsvideos. Finally, our analysis suggests that LRU performssub-optimally only at small storage ratios, and the differ-ence between LRU and OptRP-Future reduces considerablyat higher storage ratios (not considered in [6]).

Traffic engineering: Several classes of traffic engineer-ing schemes such as OSPF link-weight optimization [16],MPLS flow splitting [15], optimizing routing for multipletraffic matrices [37, 40], online engineering [22, 15], andoblivious routing [7, 9], have been studied. All of theseschemes assume that the demand traffic is a given to whichrouting must adapt. However, we find that an NCDN is ina powerful position to change the demand traffic matrix, somuch so that even a naive scheme like InverseCap, i.e., noengineering at all, suffices in conjunction with a judiciousplacement strategy and optimizing routing further adds lit-tle value. In this respect, our findings are comparable inspirit to Sharma et al. [31]. However, they focus on the im-pact of location diversity, and show that even a small, fixednumber of randomly placed replicas of each content suffice toblur differences between different engineering schemes withrespect to a capacity metric (incomparable to MLU), butfind that engineering schemes still outperform InverseCap.

8. CONCLUSIONSWe posed and studied the NCDN-mangament problem

where content distribution and traffic engineering decisionscan be optimized jointly by a single entity. Our trace-drivenexperiments using extensive access logs from the world’slargest CDN and real ISP topologies resulted in the fol-lowing key conclusions. First, simple unplanned schemesfor routing and placement of NCDN content, such as In-verseCap and LRU, outperform sophisticated, joint-optimalplacement and routing schemes based on recent historic de-mand. Second, NCDN traffic demand can be “shaped” byeffective content placement to the extent that the value ofengineering routes for NCDN traffic is small. Third, we stud-ied the value of the future knowledge of demand for place-ment and routing decisions. While future knowledge helps,what is perhaps surprising is that a small amount of addi-tional storage allows simple, unplanned schemes to performas well as planned ones with future knowledge. Finally, witha mix of NCDN and transit traffic, the benefit of traditionaltraffic engineering is commensurate to the fraction of trafficthat is transit traffic, i.e., ISPs dominated by NCDN traffic

can simply make do with static routing schemes. Overall,our findings suggest that content placement is a powerfuldegree of freedom that NCDNs can leverage to simplify andenhance traditional traffic engineering.

9. ACKNOWLEDGEMENTSWe sincerely thank our shepherd Richard Ma and the

anonymous reviewers for their feedback. This research wassupported by following grants from National Science Foun-dation: CNS-0845855, CNS-0917078, and CNS-1040781. Wethank S. Shunmuga Krishnan, Yin Lin, and Bruce M. Maggsfor their help with the Akamai trace data collection. Anyopinions expressed in this work are solely those of the au-thors and not necessarily those of National Science Founda-tion or Akamai Technologies.

10. REFERENCES[1] Akamai Licensed CDN.

http://www.akamai.com/html/solutions/aura_licensed_cdn.html.

[2] Akamai Managed CDN.http://www.akamai.com/html/solutions/aura_managed_cdn.html.

[3] Akamai, AT&T strike deal for content delivery services,December 2012. http://www.marketwatch.com/story/akamai-att-strike-deal-for-cdn-services-2012-12-06.

[4] Akamai NetSession Interface. http://www.akamai.com/client.

[5] Apple. HTTP Live Streaming. http://bit.ly/MgoUED.

[6] D Applegate, A Archer, V Gopalakrishnan, S Lee, and K KRamakrishnan. Optimal content placement for a large-scaleVoD system. In Co-NEXT, 2010.

[7] D Applegate and E Cohen. Making routing robust to changingtraffic demands: algorithms and evaluation. IEEE/ACMTrans. Netw., 14:1193–1206, December 2006.

[8] AT&T. Content Distribution, 2011. http://bit.ly/Lefgj2.

[9] Y Azar, E Cohen, A Fiat, H Kaplan, and H Racke. Optimaloblivious routing in polynomial time. In STOC, 2003.

[10] Edge Cast. EdgeCast Licensed CDN.http://www.edgecast.com/solutions/licensed-cdn/.

[11] Cisco. Visual Networking Index, 2011. http://bit.ly/KXDUaX.

[12] R Cohen and G Nakibly. A traffic engineering approach forplacement and selection of network services. IEEE/ACMTrans. Netw., 2009.

[13] J. Dilley, B. Maggs, J. Parikh, H. Prokop, R. Sitaraman, andB. Weihl. Globally distributed content delivery. InternetComputing, IEEE, 6(5):50–58, 2002.

[14] D DiPalantino and R Johari. Traffic Engineering vs. ContentDistribution: A Game Theoretic Perspective. In INFOCOM,2009.

[15] A Elwalid, C Jin, S Low, and I Widjaja. MATE: MPLSadaptive traffic engineering. In INFOCOM, 2001.

[16] B Fortz and M Thorup. Internet traffic engineering byoptimizing OSPF weights. In INFOCOM, 2000.

[17] B Fortz and M Thorup. Optimizing ospf/is-is weights in achanging world. JSAC, May 2002.

[18] B Frank, I Poese, G Smaragdakis, S Uhlig, and A Feldmann.Content-aware traffic engineering. In SIGMETRICS, 2012.

[19] HP. The edge of bandwidth growth. http://bit.ly/HwXtUO.

[20] IBM. ILOG CPLEX. http://ibm.co/KRuqhB.

[21] W Jiang, R Zhang-Shen, J Rexford, and M Chiang.Cooperative content distribution and traffic engineering in anISP network. In SIGMETRICS, 2009.

[22] S Kandula, D Katabi, B Davie, and A Charny. Walking thetightrope: responsive yet stable traffic engineering. InSIGCOMM, 2005.

[23] Chip Killian, Michael Vrable, Alex C. Snoeren, Amin Vahdat,and Joseph Pasquale. The overlay network content distributionproblem. In In Technical Report CS2005-0824, UCSD, 2005.

[24] Level3. Content Delivery Network, 2011. http://bit.ly/LvsIDm.

[25] F. Lo Presti, C. Petrioli, and C. Vicari. Distributed dynamicreplica placement and request redirection in content deliverynetworks. In In MASCOTS, 2007.

[26] Streaming Media. Telco-CDN Whitepapers.http://bit.ly/GUDrUZ.

[27] Nielsen. Online Video Usage Up 45%. http://bit.ly/MiXiPU.

[28] E Nygren, R K Sitaraman, and J Sun. The Akamai network: aplatform for high-performance internet applications. SIGOPSOper. Syst. Rev., August 2010.

[29] Lili Qiu, V.N. Padmanabhan, and G.M. Voelker. On theplacement of web server replicas. In In INFOCOM, 2001.

[30] RFC. 2616. http://www.ietf.org/rfc/rfc2616.txt.

[31] A Sharma, A Mishra, V Kumar, and A Venkataramani. BeyondMLU: An application-centric comparison of traffic engineeringschemes. In INFOCOM, 2011.

[32] A Sharma, A Venkataramani, and R Sitaraman. DistributingContent Simplifies ISP Traffic Engineering. UMASS CSTechnical Report. UM-CS-2012-002. https://web.cs.umass.edu/publication/docs/2012/UM-CS-2012-002.pdf.

[33] Abilene Topology. http://bit.ly/Lf8k7a.

[34] Vytautas Valancius, Bharath Ravi, Nick Feamster, and Alex C.Snoeren. Quantifying the benefits of joint content and networkrouting. In In SIGMETRICS, 2013.

[35] Verizon. HBO for FIOS Customers. http://bit.ly/JQ2dn8.

[36] Verizon. Velocix at Verizon, 2011. http://bit.ly/LlqGn3.

[37] H Wang, H Xie, L Qiu, Y R Yang, Y Zhang, and A Greenberg.COPE: Traffic Engineering in Dynamic Networks. InSIGCOMM, 2006.

[38] H Xie, Y R Yang, A Krishnamurthy, Y G Liu, andA Silberschatz. P4P: Provider Portal for Applications. InSIGCOMM, 2008.

[39] Hong Xu and Baochun Li. Joint request mapping and responserouting for geo-distributed cloud services. In In INFOCOM,2013.

[40] C Zhang, Y Liu, W Gong, J Kurose, R Moll, and D Towsley.On optimal routing with multiple traffic matrices. InINFOCOM, 2005.

APPENDIXA. COMPLEXITY OF NCDN PROBLEM

Opt-NCDN is the decision version of the NCDN problem(§3). Opt-NCDN asks if the MLU of the network can be αwhile satisfying the constraints of the problem.

Theorem 1 Opt-NCDN is NP-Complete even in the spe-cial case where all objects have unit size, all demands, andlink and storage capacities have binary values.

Proof: We show a reduction from the well known SetCoverproblem defined as follows. SetCover: Let S = {1, 2, ..., n}be a set of n elements. Let X = {S1, ..., Sm} where Si ⊆S, 1 ≤ i ≤ m. Let k be an integer. SetCover asks if thereexists Y = {Y1, ..., Yk}, where Yk ∈ X and Y1 ∪ ...∪ Yk = S.Set Y is called a set cover of size k.

The reduction from SetCover to Opt-NCDN is describedusing the network in Figure 15. Set V1 = {1, ...,m} refersto nodes in the top row. Each node i ∈ V1 maps to the setSi ⊂ S. Set V2 = {1, ..., n} refers to nodes in the bottomrow excluding node s. Each node i ∈ V2 maps to elementi ∈ S. Node s is called a special node.

Directed links (i, j) exist from all nodes i ∈ V1 to all nodesj ∈ V2. The capacity of (i, j) is 1 unit if i ∈ Sj , otherwisecapacity is zero. Node s has incoming links (i, s) from allnodes i ∈ V1 such that the capacity of all incoming links is 1unit. All nodes in the top row V1 have unit storage whereasnodes in the bottom row V2 ∪ {s} have zero storage.

The set of objects is {o, 1, 2, ..., (m − k)} and all objectshave unit size. Object o is a special object that has unitdemand at nodes in set V2 = {1, ..., n} and zero demand atall other nodes. Objects 1, 2, .. (m− k) have unit demandat special node s and zero demand at all other nodes.

Claim: There is a set cover of size k if and only if theabove network can achieve MLU ≤ 1.

If there is a set cover of size k, then the network canachieve MLU of 1. Store the special object o at the k setcover locations in the top row and satisfy demand for o at

1 2 3 m

1 2 n s

A node for

each set

A node for

each element

These nodes have unit storage

but no demand for any content

These nodes have no storage but

have non-zero demand for content

Unit capacity edges

from all top nodes to

all bottom nodes.

Special node

11

11

Figure 15: Reduction from SetCover to Opt-NCDN

nodes V2 = {1, ..., n} in the bottom row from these locationswith MLU = 1. The remaining (m−k) nodes in the top canbe used for objects {1, 2, ..., (m− k)} to satisfy the demandat special node s with MLU of 1.

If there is no set cover of size k, then the network musthave a MLU > 1. Objects must be placed in some (m− k)nodes in the node V1 = {1, ...,m} in the top row to satisfythe demand for special node s. Thus, at most k nodes areavailable for placing special object o. Since there is no setcover of size k, some bottom node i ∈ V2 must satisfy itsdemand for special object o using an edge whose capacity iszero resulting in MLU = ∞ on that edge.

It is easy to show that Opt-NCDN ∈ NP. Hence, Opt-NCDN is NP-Complete.

Theorem 2 Opt-NCDN is inapproximable within a factorβ for any β > 1 unless P = NP.

The proof of Theorem 1 shows that if there is a set coverof size k, MLU = 1 and MLU = ∞ otherwise. Thus, if wefind a solution for which MLU is finite, it implies that MLU= 1, which immediately gives a solution to the correspondingSetCover instance.

Lets assume a β-approximation (β > 1) exists for Opt-NCDN. Then, we can solve SetCover in polynomial timeby mapping SetCover instance to Opt-NCDN instance, andchecking if MLU≤ β (which implies MLU = 1). As SetCover∈ NP-Complete, therefore, no β−approximation for Opt-NCDN exists unless P = NP.