Optimizing CDN Infrastructure for Live Streaming with Constrained Server Chaining
0 likes305 views
This document proposes a method called Constrained Server Chaining (CSC) to optimize CDN infrastructure for live streaming. CSC allows CDN streaming servers to dynamically select upstream servers to pull live streams from, rather than only pulling from fixed ingest servers. This allows streaming servers to form constrained chains to minimize total transit costs for the CDN provider while ensuring end user experience is not compromised by capping delivery path lengths. The document outlines the problem definition, design overview, and software architecture of CSC and provides an example to motivate how CSC can reduce costs compared to traditional layered CDN structures.
![Optimizing CDN Infrastructure for Live Streaming
with Constrained Server Chaining
Zhenyun Zhuang∗ and Chun Guo†
∗College of Computing, Georgia Institute of Technology, Atlanta, GA 30332, USA
Email: zhenyun@cc.gatech.edu
†Ying-Da-Ji Technologies, 603 Overseas High-Tech Venture Park,
NanShan District, Shenzhen 518057, China
Abstract—Content Delivery Networks (CDNs) are increasingly
being used to deliver live streaming on today’s Internet. The new
application type of live streaming exposes unique characteristics
and challenges that require more advanced design of CDN
infrastructure. Unlike traditional web-object delivering, which
allows CDN content servers to cache contents and thus typically
only involves certain CDN servers (e.g. edge content servers) for
delivering contents, live streaming requires a real-time full CDN
streaming path that spans across the streaming source, the CDN
ingest server, the CDN content server, and end-viewers. Though
the ingest server is typically fixed for a particular live stream,
appropriate content servers need to be selected for delivering the
stream to end viewers.
Though today’s CDNs typically employ layered infrastructure
for delivering live streaming, in this work, we propose a flat-
layered design which is referred to as Constrained Server
Chaining (CSC) for selecting optimal content servers to deliver
live streams. Rather than employing a strictly layered infrastruc-
ture, CSC allows CDN streaming servers to dynamically choose
upstream servers, thus saves transit cost for CDN providers.
I. INTRODUCTION
Content Delivery Networks (CDNs) [1]–[5] have been in-
tensively used to deliver both static and dynamic web contents.
A typical CDN infrastructure consists of Ingest Servers (for
accepting customer contents), Origin Servers (for serving edge
servers) and Edge Servers (for serving end users directly),
forming a layered structure. Depending on the scale of a CDN,
the number of servers varies from several to hundreds or even
thousands.
Live streaming is becoming increasingly popular, and it
is expected to be more pervasive in the near future. Major
CDN providers such as Akamai [1], Level3 [4], Limelight
[5] and Internap [3] are supporting delivering live streaming
with CDNs. When supporting live streaming, CDN servers
are divided into two categories based on their functionalities:
(i) Ingest Servers which accept customers’ live streams; and
(ii) Streaming Servers which transit live streams from ingest
servers to end users. Following the convention of serving web
contents, CDN providers typically organize these servers into
layered-structure and force streaming servers to retrieve live
streams from ingest servers and then serve to end viewers. 1
1Some CDNs further split streaming servers into edge and origin streaming
servers and force edges to retrieve from origins. For these CDNs, the notion
of streaming servers applies to both edge and origin servers.
Unlike other traditional web-based applications, live stream-
ing is associated with unique characteristics and in turn
presents special challenges to CDN infrastructures. First, a live
stream has to be delivered from the CDN ingest server to end
viewers (via other CDN servers) in a real-time fashion, which
is in sharp contrast with traditional CDN-based web delivering
where typically only the last hop (i.e., from CDN servers to
web users) needs to be optimized. Second, live streaming often
features high-bandwidth requirement. A typical live stream can
easily consumes up to 3 Mbps, thus there is a higher need for
reducing transit cost on CDN networks.
Though effectively addressing all challenges associated with
live streaming requires advanced design/redesign of many
mechanisms of CDN infrastructure, in this work, we focus
on optimizing the structure of CDN streaming servers and
propose a design called Constrained Server Chaining (CSC)
for supporting live streaming. CSC’s key idea is to allow CDN
streaming servers to form a constrained chain structure for
pulling live streams from the ingest server and delivering to
end viewers.
In the following presentation, we first provide some back-
ground information and motivate our design of CSC in Section
II. We then present the problem definition and the detailed
design of CSC in Section III and Section IV, respectively.
We perform prototype-based evaluation and show the results
in Section V. We also present related works in Section VI.
Finally we conclude the work in VII.
II. BACKGROUND AND MOTIVATION
Unique properties of live streaming motivate advanced
design of infrastructure for CDN providers. In this section,
we first provide some background information about CDN
and live streaming. We then use an illustrative example to
demonstrate the potential improvements with an optimized
infrastructure.
A. Backgrounds
CDN: CDNs can be used to deliver both static/dynamic
web contents and live streams. A typical CDN infrastructure
consists of ingest servers, origin servers and edge servers.
Depending on the scale of a CDN, the number of edge servers
typically vary from dozens to tens of thousands. The number of
origin servers is less than that of edge servers, while a typical](https://image.slidesharecdn.com/2011-160507181836/85/Optimizing-CDN-Infrastructure-for-Live-Streaming-with-Constrained-Server-Chaining-1-320.jpg)
![Server
Connection
Monitoring (SCM)
Server
Streaming
State
Cost Determination
(CD)
CSC
Engine
User
Request
Optimal
Streaming
Server
Connecting/
disconnecting
Cost
Updating
State
Retrieval
Server-Server
Cost State
State
Retrieval
Length Cap Determination (LCD)Assignment/Updating
Fig. 2. Software Architecture
Variables
Ui: New live stream user
LMk: requested live stream
SSei: The streaming server that serves Ui
CSSi: The candidate streaming server set
OSSo: The optimal upstream streaming server
1 Received a new live stream playback request from Ui
2 Determine the streaming server SSei that will serve Ui
3 Check whether SSei is serving LMk or not
4 If SSei is serving LMk
5 Begin playback
6 Else
7 Retrieve state information
8 Determine candidate streaming server set CSSi
9 Retrieve state of cost values and streaming
10 Determine the optimal upstream server OSSo
11 (The cost between SSei and OSSo is minimum)
12 Update server streaming state
13 End
Fig. 3. Pseudo code of CSC
C. Software Architecture and Overall Process
The software architecture of CSC is shown in Figure 2.
The heart of CSC is the CSC Engine, which takes the user
request, interacts with other components, and then decides
the optimal upstream streaming server. CSC selects streaming
servers based on the cost associated with the live streaming
delivery path, and the cost is CDN-specific. CSC maintains
the state of the cost values of each CDN hops and the server
streaming state for each live stream. The server-server cost
is determined by another component of Cost Determination
(CD), and the server streaming state is adjusted by Server
Connection Monitoring (SCM), which updates state whenever
a connection between CDN servers is setup or dismantled.
The overall process of how CSC works is as follows. When
a new live streaming viewer begins to playback a stream,
the direct CDN streaming server will be determined (e.g.,
by CDN’s GeoDNS service [6]). If the streaming server is
actively serving the stream, then it sends the stream to the user.
Otherwise, CDN will then attempt to determine the optimal
upstream streaming server. For this, the CSC engine retrieves
the cost values and streaming state of streaming servers, and
it then determines the candidate streaming server set. Each of
the streaming server in the candidate set has to satisfy three
requirements: (i) actively serving the requested stream; (ii)
available for more retrieval (e.g., not overloaded); and (iii)
retrieval from it does not compromise the length cap. Based
on the candidate set, CSC engine then selects the optimal
streaming server that incurs the smallest transit cost (i.e., the
transit cost between the selected upstream server and the direct
streaming server). Finally, it updates the streaming server state
and begins stream retrieval. CSC’s pseudo code is shown in
Figure 3.
D. Illustrative example
We now use an example to illustrate how CSC works.
Assuming a CDN has 1 ingest server I1 and 3 streaming
servers (S1, S2 and S3) to serve a particular live stream, as
shown in Figure 4(A).
When the first user U1 joins, it obtains the stream from S1.
Since other streaming servers are not serving the stream, S1
directly pulls from I1, as shown in in Figure 4(B). When the
second user U2 begins pulling the stream from S2, S2 notices
that both S1 and I1 are available upstream servers. Since S1 is
closer to it, S2 pulls from S1, as shown in Figure 4(C).
Finally, when U3 joins, its streaming server S3 can pull from
either I1, S1 or S2. Though S2 is the closest server to S3,
pulling from S2 results in a longer path compared to directly
connecting to I1. Assuming connecting to S2 will result in a
delivery path (i.e., I1S1S2S3) that exceeds the length threshold,
then S2 will not be included in the candidate streaming server
set. Thus, S3 will instead pull from I1, which results in a setup
shown in in Figure 4(D).
IV. CSC COMPONENTS
We now describe the detailed design of CSC components.
A. Cost Determination (CD)
In order to perform CSC operations, each delivery hop
(i.e., ingest-server to streaming-server and streaming-server to
streaming-server) on CDN infrastructure has to be associated
with quantifiable cost. Note that in this work for easier
presentation we use physical distance as the sample cost, but
it should be straightforward to define other types of cost such
as network distance, price, and reliability, etc. For instance,
using Dij and Pij to denote the physical distance and pricing
of the network path between servers i and j, respectively, a](https://image.slidesharecdn.com/2011-160507181836/85/Optimizing-CDN-Infrastructure-for-Live-Streaming-with-Constrained-Server-Chaining-3-320.jpg)
![I1
S1
S2
S3 S1
S2
S3 S1
S2
S3 S1
S2
S3
(A) (B) (C) (D)
I1 I1 I1
Fig. 4. Illustrative Example
CDN provider could derive a new cost of DPij by composing
the two types of cost. The detailed definition of combined cost
metrics is beyond the scope of this work.
B. Length Cap Determination (LCD)
Length Cap Determination (LCD) component maintains the
desired delivery length cap imposed by either CDN providers
or customers. Delivery length can be measured in the forms
of physical distance, network delay, number of intermediate
streaming servers, or network hops. The most simple fashion
to enforce length cap is to ask CDN providers to set the cap
values based on network environment, but it is desirable to
allow each customer to control per-stream cap values, since
each customer and stream may have different requirements on
delivery latency. The customer can preset the values for each
stream with CDN providers or set the values on-the-fly. For
instance, with Adobe Live Encoder and Flash Stream Servers,
the customer sources could use NetConnection.Connect() call
to pass-in cap values for each stream in Flash players.
C. Server Connection Monitoring (SCM)
The component of SCM (Server Connection Monitoring) is
used to keep the server streaming state fresh, in the sense
that whether a streaming server is actively serving a live
stream is up-to-date. SCM monitors the events of connection
and disconnection occurring on streaming servers. When a
streaming server receives requests from end viewers and
begins pulling from another streaming server or ingest server, a
connection event occurs. On the other hand, when a streaming
server is disconnected by all end viewers and stops pulling
from upstream CDN streaming servers, a disconnection event
occurs. For both types of events, SCM updates corresponding
state accordingly.
To capture the events of connections and disconnections,
streaming servers should have the ability to monitor such
events. The capability can be implemented inside various live
streaming servers that directly serve viewers. Examples of
live streaming servers are Wowza Media Server, Adobe Media
Server and IIS smooth streaming server. The capability could
be implemented in the form of server plug-ins.
D. Maintained States
CSC maintains two types of state information: Server-server
cost and Server streaming state. The server-server cost will
be maintained as a 2-dimension array, e.g., COST[NS][NS],
where NS is the set size of all CDN servers (i.e., both ingest
servers and streaming servers). The cost information will be
used by all live streams being delivered by the particular CDN.
The server streaming state will be maintained as a 2-
dimension array, e.g., STREAMING[NS][NM], where NS is
the set size of CDN servers, and NM is the set size of live
streams. Initially all elements of STREAMING are set to
zero. When a streaming server CSi starts playing a stream
LMj, STREAMING[i][j] will be set to 1. When an streaming
server CSi stops playing a stream LMj, then corresponding
STREAMING array element will be reset to 0.
E. CSC Engine
CSC Engine performs the actually computation and com-
parison of costs, then selects the most appropriate upstream
streaming server given a live streaming pulling request.
When such requests come, CSC engine firstly decides
the streaming server that will directly serve the user. The
determination can be easily done by CDN’s existing server-
selection mechanism (e.g., GeoDNS). If the streaming server
is actively serving the stream (i.e., STREAMING[][] element
is 1), then the stream is immediately served and no further
actions will be taken.
If the streaming server is not actively serving the stream,
CSC engine then decides the candidate streaming servers
by filtering out the unavailable or overloaded servers, then
retrieves the server-server cost, server streaming state, and
the length cap values for the particular stream. With a set
of candidate streaming servers, it then determines the optimal
upstream streaming server to pull the stream from based on
the algorithms described in Figure 3.
V. EVALUATION
To gain concrete understanding of CSC regarding the im-
pact on both CDN and viewers, we consider the following
simplified scenario to quantify the saving on CDN transit cost
and the performance experienced by end viewers. We assume
an USA mainland CDN provider which has 1 ingest POP
(Point of Presence) and 4 streaming POPs, where each POP
has only a single server. We further assume a default layered-
CDN scenario where each streaming server has to retrieve
live streams from the ingest server. For comparison, we also
assume a CSC-applied scenario where streaming servers can
retrieve live streams from either other streaming servers or the
ingest server.
For simplicity, we consider a simple performance metric of
physical distance in the unit of thousand-miles (i.e., KMiles)
for both CDN transit-cost saving and live-stream viewers.](https://image.slidesharecdn.com/2011-160507181836/85/Optimizing-CDN-Infrastructure-for-Live-Streaming-with-Constrained-Server-Chaining-4-320.jpg)
![Ingest: I
Server: S2
Server: S1
Server: S3
Source: S
Server: S4
(a) Prototype map
User: U1
Ingest: I
Server: S2
Server: S1
User: U2
Server: S3
User: U3
Source: S
Server: S4
User: U4
(b) Default CDN
User: U1
Ingest: I
Server: S2
Server: S1
User: U2
Server: S3
User: U3
Source: S
Server: S4
User: U4
(c) CSC
Fig. 5. Prototype Testbed
Thus, the larger the distances are, the higher cost CDN
providers pay.
A. Prototype Setup
We built a prototype with Adobe Flash Media Server (FMS)
4.0. The prototype consists of 5 servers deployed in 5 cities,
all running Windows Server 2008 R2. One of the servers
(I) is accepting live stream injection, while other streaming
servers (S1 through S4) can serve viewers directly and pull
streams from other servers, as shown in Figure 5(a). The
streaming source encoder is Flash Media Live Encoder 3.1.
Both ingesting and streaming protocols are RTMP.
The streaming servers run customized Server Side Action-
Script to dynamically pull from appropriate streaming servers
(Sample code shown in Figure 6). Specifically, when a player
issues NetConnection.connect(“rtmp://S1/app1/stream1”,
[cap-values]) call to streaming server S1 requesting live
stream stream1 of application app1, if S1 is serving stream1,
it will just do acceptConnection(). Otherwise, if S1 is not
serving stream1, it first determines the optimal streaming
server to pull from. It then creates a Stream object and pulls
from the optimal streaming server. The cap-values passed in
with the call is also remembered for CSC engine.
In the evaluation, there are totally 4 users, and their joining
sequence is U1 through U4. Note that each of the user is
directly served by S1 through S4, respectively. We first consider
the default scenario where layered CDN infrastructure is firmly
enforced. The stream delivering map is shown in Figure 5(b).
As shown, all streaming servers pull the live stream from I.
For comparison, we also consider an optimized flat scenario
where CSC is applied, and the eventual network setup is shown
in Figure 5(c). S1 and S4 are directly pulling streams from I,
while S2 and S3 rely on S1 for relaying.
application.onAppStart = function(){
CurServers = ObtainCandidateServers(“stream1”);
OptimalServer = DecideOptimalServer(CurServers);
nc = new NetConnection(); //Retrieval from OptimalServer
myStream = Stream.get(“stream1”);
nc.onStatus = function(info){
if(info.code == “NetConnection.Connect.Success” ){
myStream.play(“stream1”, -1, -1, true, nc);
} }
nc.connect(“rtmp://OptimalServer/app1”);
}
Fig. 6. FMS Server Side Code for Handling “app1/stream1” Request
B. CDN Transit Cost
Since we use the cost metric of physical distance, in the
following we show the transit cost results in the unit of
KMiles. For both scenarios, we count the CDN delivery
lengths of server-server paths for each streaming server and the
aggregated CDN delivery path. As shown in Figure 7, the blue
bars show the default scenario, while the red bars show the
CSC scenario. Specifically, first, out of four CDN delivering
paths, two paths (i.e., IS2 and IS3) are shorter than the default
scenario, while the other two paths (i.e., IS1 and IS4) are the
same as in the default scenario.
Second, the aggregated server-server distances are 5.78
Kmiles and 3.64 Kmiles for two scenarios, respectively. The
reason for reduced distance in CSC scenario is that some
streaming servers (i.e., S2 and S3) are pulling from S1 as
opposed to from I. For the particular setup, CSC results in
much smaller CDN transit cost (more than 37% of reduction).
These results suggest that CSC is able to gain significant
transit cost saving inside CDN. Note that in this simple
scenario, we assume each POP only has a single CDN server.
With more servers, the saved transit cost can be more signifi-
cant as each server will incur a separate delivery path.
C. Delivery Lengths of Individual Viewers
Since each live stream has to delivered from the stream
source all the way to the end users in a real-time fashion, the
end-users’ performance could be impacted by the length of
the entire delivery path in the form of start-up playback delay
and path reliability. Specifically, with a longer delivery path,
an user oftentimes experiences larger playback delay, and the
connection is more likely less reliable.
We plot the CDN delivery length of each individual user
in Figure 7(b). We observe that U1 and U4 have the same
delivery lengths in both scenarios, while U2 and U3 experience
longer paths with CSC. The aggregated distances for the two
scenarios are 10.41 Kmiles and 11.42 Kmiles, respectively,
or 9.70% of increase. These results show that some users’
experience can be slightly negatively affected by CSC, which
is expected, as apparently the default layered star-like network
results in shortest paths for each individual user.
Note that CDN providers often optimize the CDN delivery
paths (i.e., paths between CDN servers). For instance, Akamai
[1] and Internap [3] optimize their networks with patented
techniques [7], [8]. Therefore, it is important to realize that the](https://image.slidesharecdn.com/2011-160507181836/85/Optimizing-CDN-Infrastructure-for-Live-Streaming-with-Constrained-Server-Chaining-5-320.jpg)
![0.00
1.00
2.00
3.00
4.00
5.00
6.00
7.00
S1 S2 S3 S4 Total
Default
CSC
(a) CDN Transit Cost
0
2
4
6
8
10
12
U1 U2 U3 U4 Total
Default
CSC
(b) Individual Delivery Paths
Fig. 7. CDN transit cost and user experience
user-experienced performance will not be affected significantly
even with longer delivery path.
D. Money Talks
Taking a more direct business perspective, we now compare
the transit cost with respect to the pricing of bandwidth usage.
Depending on subscription packages, CDN providers may
need to pay ISPs for the bandwidth used. We assume each live
stream is 3Mbps. In the above scenario where only 4 streaming
servers are delivering the live stream, the saved bandwidth
per day would be 0.07 TB*Kmiles (or 25.35 TB*KMiles per
year). With 3000 streams, the saved bandwidth would be 210
TB*Kmiles (or 76.04 PB * Kmiles per year).
Though the exact CDN transit pricing varies across time
and subscription packages, we attempt to obtain concrete
cost values by simply assuming the transit cost of 0.10 per
GB/Kmile. With such a cost, CSC can help save $7.60 Million
per year with 3000 streams, or about $2.53K per stream.
VI. RELATED WORK
Content Delivery Networks (CDNs) have been carried out
by various providers to expedite the web access [1]–[5]. The
techniques used by CDNs for delivering conventional web
contents are explained in related writings [9], [10]. Despite
the popularity and pervasiveness of CDNs, many research
problems and system-building challenges persist for optimiz-
ing CDN infrastructure and addressing challenges associated
supporting various types of applications. For instance, as we
demonstrated in this work, how to efficiently support the
application of live streaming with CDNs deserves more study.
Though various network architectures have been proposed
and utilized for different deployment scenarios with the rapid
development of Internet technology [11]–[14], CDN providers
typically apply layered structure (e.g., ingest-layer, origin-
layer and edge-layer) due to the caching-property of delivering
static web contents tracing back to Day-1 of CDN industry.
Realizing that CDNs and P2P can complement each other,
many research efforts also attempt to integrate these two
realms into one [15]. Unlike these works that combine the
merits of both CDNs and P2P, our work takes an inside
perspective and attempts to refine CDN delivery infrastructure.
Live streaming has been studied and analyzed from various
perspectives [16]–[18]. The unique properties of live stream-
ing, coupled with CDN-assisted delivery, justifies a specialized
design of CDN infrastructure that specifically serves live
streaming and saves CDN transit cost. To our best knowledge,
this work is the first to consider and address the problem of
saving transit cost for delivering live streaming with CDNs.
VII. CONCLUSION
In this work, we propose a flat CDN infrastructure for
delivering live streaming with CDNs. Referred to as CSC, the
new infrastructure can greatly reduce CDN transit cost without
significantly affecting users’ experience.
REFERENCES
[1] “Akamai technologies,” http://www.akamai.com/.
[2] “At&t inc.” http://www.att.com/.
[3] “Internap network services corporation,” http://www.internap.com/.
[4] “Level 3 communications, llc.” http://www.level3.com/.
[5] “Limelight networks,” http://www.limelightnetworks.com/.
[6] “Bind geodns,” http://www.caraytech.com/geodns/.
[7] Internap-MIRO, “Method and system for optimizing routing through
multiple available internet route providers,” 2005.
[8] A. Patent, “Optimal route selection in a content delivery network,”
United States Patent 7274658, 2007.
[9] K. Park, W. W. (editors, H. Kung, and C. Wu, “Content networks:
Taxonomy and new approaches,” 2002.
[10] D. C. Verma, S. Calo, and K. Amiri, “Policy based management of
content distribution networks,” IEEE Network Magazine, vol. 16, pp.
34–39, 2002.
[11] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan,
“Chord: A scalable peer-to-peer lookup service for internet applications,”
in SIGCOMM ’01: Proceedings of the 2001 conference on Applications,
technologies, architectures, and protocols for computer communications,
San Diego, CA, USA, 2001.
[12] A. I. T. Rowstron and P. Druschel, “Pastry: Scalable, decentralized
object location, and routing for large-scale peer-to-peer systems,” in
Middleware ’01: Proceedings of the IFIP/ACM International Conference
on Distributed Systems Platforms Heidelberg, London, UK, 2001.
[13] S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Schenker, “A
scalable content-addressable network,” in SIGCOMM ’01: Proceedings
of the 2001 conference on Applications, technologies, architectures, and
protocols for computer communications, San Diego, CA, USA, 2001.
[14] I. Stoica, D. Adkins, S. Zhuang, S. Shenker, and S. Surana, “Internet
indirection infrastructure,” IEEE/ACM Trans. Netw., vol. 12, no. 2, pp.
205–218, 2004.
[15] H. Yin, X. Liu, T. Zhan, V. Sekar, F. Qiu, C. Lin, H. Zhang, and B. Li,
“Livesky: Enhancing cdn with p2p,” ACM Trans. Multimedia Comput.
Commun. Appl., vol. 6, pp. 16:1–16:19, August 2010.
[16] K. Sripanidkulchai, B. Maggs, and H. Zhang, “An analysis of live
streaming workloads on the internet,” in Proceedings of the 4th ACM
SIGCOMM conference on Internet measurement, ser. IMC ’04, 2004.
[17] J. He, A. Chaintreau, and C. Diot, “A performance evaluation of scalable
live video streaming with nano data centers,” Comput. Netw., vol. 53,
pp. 153–167, February 2009.
[18] C. Vicari, C. Petrioli, and F. L. Presti, “Dynamic replica placement and
traffic redirection in content delivery networks,” SIGMETRICS Perform.
Eval. Rev., vol. 35, December 2007.](https://image.slidesharecdn.com/2011-160507181836/85/Optimizing-CDN-Infrastructure-for-Live-Streaming-with-Constrained-Server-Chaining-6-320.jpg)
Optimizing CDN Infrastructure for Live Streaming with Constrained Server Chaining
- 1. Optimizing CDN Infrastructure for Live Streaming with Constrained Server Chaining Zhenyun Zhuang∗ and Chun Guo† ∗College of Computing, Georgia Institute of Technology, Atlanta, GA 30332, USA Email: zhenyun@cc.gatech.edu †Ying-Da-Ji Technologies, 603 Overseas High-Tech Venture Park, NanShan District, Shenzhen 518057, China Abstract—Content Delivery Networks (CDNs) are increasingly being used to deliver live streaming on today’s Internet. The new application type of live streaming exposes unique characteristics and challenges that require more advanced design of CDN infrastructure. Unlike traditional web-object delivering, which allows CDN content servers to cache contents and thus typically only involves certain CDN servers (e.g. edge content servers) for delivering contents, live streaming requires a real-time full CDN streaming path that spans across the streaming source, the CDN ingest server, the CDN content server, and end-viewers. Though the ingest server is typically fixed for a particular live stream, appropriate content servers need to be selected for delivering the stream to end viewers. Though today’s CDNs typically employ layered infrastructure for delivering live streaming, in this work, we propose a flat- layered design which is referred to as Constrained Server Chaining (CSC) for selecting optimal content servers to deliver live streams. Rather than employing a strictly layered infrastruc- ture, CSC allows CDN streaming servers to dynamically choose upstream servers, thus saves transit cost for CDN providers. I. INTRODUCTION Content Delivery Networks (CDNs) [1]–[5] have been in- tensively used to deliver both static and dynamic web contents. A typical CDN infrastructure consists of Ingest Servers (for accepting customer contents), Origin Servers (for serving edge servers) and Edge Servers (for serving end users directly), forming a layered structure. Depending on the scale of a CDN, the number of servers varies from several to hundreds or even thousands. Live streaming is becoming increasingly popular, and it is expected to be more pervasive in the near future. Major CDN providers such as Akamai [1], Level3 [4], Limelight [5] and Internap [3] are supporting delivering live streaming with CDNs. When supporting live streaming, CDN servers are divided into two categories based on their functionalities: (i) Ingest Servers which accept customers’ live streams; and (ii) Streaming Servers which transit live streams from ingest servers to end users. Following the convention of serving web contents, CDN providers typically organize these servers into layered-structure and force streaming servers to retrieve live streams from ingest servers and then serve to end viewers. 1 1Some CDNs further split streaming servers into edge and origin streaming servers and force edges to retrieve from origins. For these CDNs, the notion of streaming servers applies to both edge and origin servers. Unlike other traditional web-based applications, live stream- ing is associated with unique characteristics and in turn presents special challenges to CDN infrastructures. First, a live stream has to be delivered from the CDN ingest server to end viewers (via other CDN servers) in a real-time fashion, which is in sharp contrast with traditional CDN-based web delivering where typically only the last hop (i.e., from CDN servers to web users) needs to be optimized. Second, live streaming often features high-bandwidth requirement. A typical live stream can easily consumes up to 3 Mbps, thus there is a higher need for reducing transit cost on CDN networks. Though effectively addressing all challenges associated with live streaming requires advanced design/redesign of many mechanisms of CDN infrastructure, in this work, we focus on optimizing the structure of CDN streaming servers and propose a design called Constrained Server Chaining (CSC) for supporting live streaming. CSC’s key idea is to allow CDN streaming servers to form a constrained chain structure for pulling live streams from the ingest server and delivering to end viewers. In the following presentation, we first provide some back- ground information and motivate our design of CSC in Section II. We then present the problem definition and the detailed design of CSC in Section III and Section IV, respectively. We perform prototype-based evaluation and show the results in Section V. We also present related works in Section VI. Finally we conclude the work in VII. II. BACKGROUND AND MOTIVATION Unique properties of live streaming motivate advanced design of infrastructure for CDN providers. In this section, we first provide some background information about CDN and live streaming. We then use an illustrative example to demonstrate the potential improvements with an optimized infrastructure. A. Backgrounds CDN: CDNs can be used to deliver both static/dynamic web contents and live streams. A typical CDN infrastructure consists of ingest servers, origin servers and edge servers. Depending on the scale of a CDN, the number of edge servers typically vary from dozens to tens of thousands. The number of origin servers is less than that of edge servers, while a typical
- 2. (a) Default Delivery (b) Optimized Delivery Fig. 1. Live streaming delivered with CDN CDN only has a handful of ingest servers. Various servers are organized into POPs (i.e., Point Of Presence). Live Streaming: Live streaming is a new type of applica- tion that is increasingly being delivered by CDNs. Featuring properties different from static contents, live streaming typi- cally has high bandwidth requirement which exerts much pres- sure to the underlying CDN infrastructure in the form of high transit cost. Unlike static web contents, live streams cannot be cached and have to maintain a full path from the customer streaming source to the end viewers/users. Various types of streaming servers can be used to support live streaming, and many of them (e.g., Adobe Flash Media Server) allow the chaining of streaming servers when delivering live streams. B. Motivating example Consider an example where Source S is ingesting a live stream into CDN’s ingest server I. Assuming both streaming servers S1 and S2 serve live streams to users. With strictly layered CDN structure, both S1 and S2 have to pull the stream from I, resulting CDN transit hops of IS1 and IS2, as shown in Figure 1(a). However, as shown in Figure 1(b), there exists another transit structure which allows S2 to pull the stream from S1 as opposed to I. The two CDN transit hops of IS1 and S1S2 have a smaller aggregated CDN transit cost, as S1S2 is shorter than IS2. Note that though the shown example is trivial at a first look, the cost saving of a CDN with many streaming servers can be huge. Specifically, the layered CDN will always result in a star-like delivery map, while a tree-like delivery map can have significantly shorter delivery path. 2 III. DESIGN OF CSC In this section, we present the design of Constrained Server Chaining (CSC). We begin by defining the problem. We then present the design overview of CSC, its software architecture, and the entire process with an illustrative example. A. Problem definition We consider the scenarios where a CDN provider has two types of servers: ingest servers which accept published live streams from customers, and streaming servers that transit the streams to end users. We use IS and SS to denote the two server sets, respectively. The CDN provider delivers a set of live 2Though the full delivery paths for some users are longer with tree-like structure, the lengths can be easily capped by exerting some restrictions on the sever selection process. We will address this concern in Section III. streams denoted by LM. We further assume each live stream LMi has a single ingesting source which connects to the ingest server of ISi. The problem we are addressing with CSC can be de- fined as follows. For each of the live streams (denoted by LMi and ingested to ISi), CSC needs to decide the optimal streaming server set OSSi such that the CDN transit cost can be minimized, and the end viewers’ experience is not adversely compromised (which is captured by imposing a delivery length cap). We use Ci to denote the aggregated transit cost corresponding to the delivering LMi across ISi and OSSi. With these assumptions, the input, output, and objective function of CSC are: • Input: (i) Live stream LMi, (ii) CDN ingest server ISi, (iii) CDN streaming server set SS, and (iv) Delivery length cap; • Output: Optimal streaming server set OSSi; • Objective function: Total CDN transit cost is minimized. B. Design Overview As we observed from the illustrate example, CDN transit cost (i.e., between CDN servers) can be saved by allowing streaming servers to retrieve live streams from other streaming servers rather than always retrieving from the CDN ingest server. Such a design essentially converts the layered infras- tructure most CDN providers are using to flat infrastructure. CSC is a specialized server-selection mechanism designed for live streaming applications. It aims at saving CDN transit cost but not compromising end user experience. Note that in this work, for ease of presentation, we use the distance as the cost metric; but it would be easy to extend the cost metric to include other factors such as pricing. We will revisit the cost metric in Section IV. CSC achieves the cost savings by allowing streaming servers to pull live streams from other closer streaming servers. In other words, rather than simply retrieving from the ingest server as in a layered structure, streaming servers can con- nect to other streaming servers to form a flat and layer-less structure. In doing so, however, the resulting delivery path for certain viewers playing the particular stream could be inflated in the form of larger distances, which could cause other undesirable effect such as larger playback-buffering time. To address this, CSC imposes length-cap when making decisions of selecting upstream servers. It always choose streaming servers that satisfy the length-cap requirement. Whenever necessary, it can also fall back to the default behavior of directly pulling from ingest servers. We will elaborate on discussions of length-cap in Section IV. CSC’s operations are per-stream based, thus it maintains appropriate state for every live stream. Specifically, for each live stream, the active streaming servers that currently are serving it are recorded so that other streaming servers can retrieve from them. In addition to the per-stream state, CSC also maintains a cost state that is used by all live streams. Cost state maintains the server-server transit cost for each pairs of CDN servers (i.e., ingest-streaming and streaming-streaming).
- 3. Server Connection Monitoring (SCM) Server Streaming State Cost Determination (CD) CSC Engine User Request Optimal Streaming Server Connecting/ disconnecting Cost Updating State Retrieval Server-Server Cost State State Retrieval Length Cap Determination (LCD)Assignment/Updating Fig. 2. Software Architecture Variables Ui: New live stream user LMk: requested live stream SSei: The streaming server that serves Ui CSSi: The candidate streaming server set OSSo: The optimal upstream streaming server 1 Received a new live stream playback request from Ui 2 Determine the streaming server SSei that will serve Ui 3 Check whether SSei is serving LMk or not 4 If SSei is serving LMk 5 Begin playback 6 Else 7 Retrieve state information 8 Determine candidate streaming server set CSSi 9 Retrieve state of cost values and streaming 10 Determine the optimal upstream server OSSo 11 (The cost between SSei and OSSo is minimum) 12 Update server streaming state 13 End Fig. 3. Pseudo code of CSC C. Software Architecture and Overall Process The software architecture of CSC is shown in Figure 2. The heart of CSC is the CSC Engine, which takes the user request, interacts with other components, and then decides the optimal upstream streaming server. CSC selects streaming servers based on the cost associated with the live streaming delivery path, and the cost is CDN-specific. CSC maintains the state of the cost values of each CDN hops and the server streaming state for each live stream. The server-server cost is determined by another component of Cost Determination (CD), and the server streaming state is adjusted by Server Connection Monitoring (SCM), which updates state whenever a connection between CDN servers is setup or dismantled. The overall process of how CSC works is as follows. When a new live streaming viewer begins to playback a stream, the direct CDN streaming server will be determined (e.g., by CDN’s GeoDNS service [6]). If the streaming server is actively serving the stream, then it sends the stream to the user. Otherwise, CDN will then attempt to determine the optimal upstream streaming server. For this, the CSC engine retrieves the cost values and streaming state of streaming servers, and it then determines the candidate streaming server set. Each of the streaming server in the candidate set has to satisfy three requirements: (i) actively serving the requested stream; (ii) available for more retrieval (e.g., not overloaded); and (iii) retrieval from it does not compromise the length cap. Based on the candidate set, CSC engine then selects the optimal streaming server that incurs the smallest transit cost (i.e., the transit cost between the selected upstream server and the direct streaming server). Finally, it updates the streaming server state and begins stream retrieval. CSC’s pseudo code is shown in Figure 3. D. Illustrative example We now use an example to illustrate how CSC works. Assuming a CDN has 1 ingest server I1 and 3 streaming servers (S1, S2 and S3) to serve a particular live stream, as shown in Figure 4(A). When the first user U1 joins, it obtains the stream from S1. Since other streaming servers are not serving the stream, S1 directly pulls from I1, as shown in in Figure 4(B). When the second user U2 begins pulling the stream from S2, S2 notices that both S1 and I1 are available upstream servers. Since S1 is closer to it, S2 pulls from S1, as shown in Figure 4(C). Finally, when U3 joins, its streaming server S3 can pull from either I1, S1 or S2. Though S2 is the closest server to S3, pulling from S2 results in a longer path compared to directly connecting to I1. Assuming connecting to S2 will result in a delivery path (i.e., I1S1S2S3) that exceeds the length threshold, then S2 will not be included in the candidate streaming server set. Thus, S3 will instead pull from I1, which results in a setup shown in in Figure 4(D). IV. CSC COMPONENTS We now describe the detailed design of CSC components. A. Cost Determination (CD) In order to perform CSC operations, each delivery hop (i.e., ingest-server to streaming-server and streaming-server to streaming-server) on CDN infrastructure has to be associated with quantifiable cost. Note that in this work for easier presentation we use physical distance as the sample cost, but it should be straightforward to define other types of cost such as network distance, price, and reliability, etc. For instance, using Dij and Pij to denote the physical distance and pricing of the network path between servers i and j, respectively, a
- 4. I1 S1 S2 S3 S1 S2 S3 S1 S2 S3 S1 S2 S3 (A) (B) (C) (D) I1 I1 I1 Fig. 4. Illustrative Example CDN provider could derive a new cost of DPij by composing the two types of cost. The detailed definition of combined cost metrics is beyond the scope of this work. B. Length Cap Determination (LCD) Length Cap Determination (LCD) component maintains the desired delivery length cap imposed by either CDN providers or customers. Delivery length can be measured in the forms of physical distance, network delay, number of intermediate streaming servers, or network hops. The most simple fashion to enforce length cap is to ask CDN providers to set the cap values based on network environment, but it is desirable to allow each customer to control per-stream cap values, since each customer and stream may have different requirements on delivery latency. The customer can preset the values for each stream with CDN providers or set the values on-the-fly. For instance, with Adobe Live Encoder and Flash Stream Servers, the customer sources could use NetConnection.Connect() call to pass-in cap values for each stream in Flash players. C. Server Connection Monitoring (SCM) The component of SCM (Server Connection Monitoring) is used to keep the server streaming state fresh, in the sense that whether a streaming server is actively serving a live stream is up-to-date. SCM monitors the events of connection and disconnection occurring on streaming servers. When a streaming server receives requests from end viewers and begins pulling from another streaming server or ingest server, a connection event occurs. On the other hand, when a streaming server is disconnected by all end viewers and stops pulling from upstream CDN streaming servers, a disconnection event occurs. For both types of events, SCM updates corresponding state accordingly. To capture the events of connections and disconnections, streaming servers should have the ability to monitor such events. The capability can be implemented inside various live streaming servers that directly serve viewers. Examples of live streaming servers are Wowza Media Server, Adobe Media Server and IIS smooth streaming server. The capability could be implemented in the form of server plug-ins. D. Maintained States CSC maintains two types of state information: Server-server cost and Server streaming state. The server-server cost will be maintained as a 2-dimension array, e.g., COST[NS][NS], where NS is the set size of all CDN servers (i.e., both ingest servers and streaming servers). The cost information will be used by all live streams being delivered by the particular CDN. The server streaming state will be maintained as a 2- dimension array, e.g., STREAMING[NS][NM], where NS is the set size of CDN servers, and NM is the set size of live streams. Initially all elements of STREAMING are set to zero. When a streaming server CSi starts playing a stream LMj, STREAMING[i][j] will be set to 1. When an streaming server CSi stops playing a stream LMj, then corresponding STREAMING array element will be reset to 0. E. CSC Engine CSC Engine performs the actually computation and com- parison of costs, then selects the most appropriate upstream streaming server given a live streaming pulling request. When such requests come, CSC engine firstly decides the streaming server that will directly serve the user. The determination can be easily done by CDN’s existing server- selection mechanism (e.g., GeoDNS). If the streaming server is actively serving the stream (i.e., STREAMING[][] element is 1), then the stream is immediately served and no further actions will be taken. If the streaming server is not actively serving the stream, CSC engine then decides the candidate streaming servers by filtering out the unavailable or overloaded servers, then retrieves the server-server cost, server streaming state, and the length cap values for the particular stream. With a set of candidate streaming servers, it then determines the optimal upstream streaming server to pull the stream from based on the algorithms described in Figure 3. V. EVALUATION To gain concrete understanding of CSC regarding the im- pact on both CDN and viewers, we consider the following simplified scenario to quantify the saving on CDN transit cost and the performance experienced by end viewers. We assume an USA mainland CDN provider which has 1 ingest POP (Point of Presence) and 4 streaming POPs, where each POP has only a single server. We further assume a default layered- CDN scenario where each streaming server has to retrieve live streams from the ingest server. For comparison, we also assume a CSC-applied scenario where streaming servers can retrieve live streams from either other streaming servers or the ingest server. For simplicity, we consider a simple performance metric of physical distance in the unit of thousand-miles (i.e., KMiles) for both CDN transit-cost saving and live-stream viewers.
- 5. Ingest: I Server: S2 Server: S1 Server: S3 Source: S Server: S4 (a) Prototype map User: U1 Ingest: I Server: S2 Server: S1 User: U2 Server: S3 User: U3 Source: S Server: S4 User: U4 (b) Default CDN User: U1 Ingest: I Server: S2 Server: S1 User: U2 Server: S3 User: U3 Source: S Server: S4 User: U4 (c) CSC Fig. 5. Prototype Testbed Thus, the larger the distances are, the higher cost CDN providers pay. A. Prototype Setup We built a prototype with Adobe Flash Media Server (FMS) 4.0. The prototype consists of 5 servers deployed in 5 cities, all running Windows Server 2008 R2. One of the servers (I) is accepting live stream injection, while other streaming servers (S1 through S4) can serve viewers directly and pull streams from other servers, as shown in Figure 5(a). The streaming source encoder is Flash Media Live Encoder 3.1. Both ingesting and streaming protocols are RTMP. The streaming servers run customized Server Side Action- Script to dynamically pull from appropriate streaming servers (Sample code shown in Figure 6). Specifically, when a player issues NetConnection.connect(“rtmp://S1/app1/stream1”, [cap-values]) call to streaming server S1 requesting live stream stream1 of application app1, if S1 is serving stream1, it will just do acceptConnection(). Otherwise, if S1 is not serving stream1, it first determines the optimal streaming server to pull from. It then creates a Stream object and pulls from the optimal streaming server. The cap-values passed in with the call is also remembered for CSC engine. In the evaluation, there are totally 4 users, and their joining sequence is U1 through U4. Note that each of the user is directly served by S1 through S4, respectively. We first consider the default scenario where layered CDN infrastructure is firmly enforced. The stream delivering map is shown in Figure 5(b). As shown, all streaming servers pull the live stream from I. For comparison, we also consider an optimized flat scenario where CSC is applied, and the eventual network setup is shown in Figure 5(c). S1 and S4 are directly pulling streams from I, while S2 and S3 rely on S1 for relaying. application.onAppStart = function(){ CurServers = ObtainCandidateServers(“stream1”); OptimalServer = DecideOptimalServer(CurServers); nc = new NetConnection(); //Retrieval from OptimalServer myStream = Stream.get(“stream1”); nc.onStatus = function(info){ if(info.code == “NetConnection.Connect.Success” ){ myStream.play(“stream1”, -1, -1, true, nc); } } nc.connect(“rtmp://OptimalServer/app1”); } Fig. 6. FMS Server Side Code for Handling “app1/stream1” Request B. CDN Transit Cost Since we use the cost metric of physical distance, in the following we show the transit cost results in the unit of KMiles. For both scenarios, we count the CDN delivery lengths of server-server paths for each streaming server and the aggregated CDN delivery path. As shown in Figure 7, the blue bars show the default scenario, while the red bars show the CSC scenario. Specifically, first, out of four CDN delivering paths, two paths (i.e., IS2 and IS3) are shorter than the default scenario, while the other two paths (i.e., IS1 and IS4) are the same as in the default scenario. Second, the aggregated server-server distances are 5.78 Kmiles and 3.64 Kmiles for two scenarios, respectively. The reason for reduced distance in CSC scenario is that some streaming servers (i.e., S2 and S3) are pulling from S1 as opposed to from I. For the particular setup, CSC results in much smaller CDN transit cost (more than 37% of reduction). These results suggest that CSC is able to gain significant transit cost saving inside CDN. Note that in this simple scenario, we assume each POP only has a single CDN server. With more servers, the saved transit cost can be more signifi- cant as each server will incur a separate delivery path. C. Delivery Lengths of Individual Viewers Since each live stream has to delivered from the stream source all the way to the end users in a real-time fashion, the end-users’ performance could be impacted by the length of the entire delivery path in the form of start-up playback delay and path reliability. Specifically, with a longer delivery path, an user oftentimes experiences larger playback delay, and the connection is more likely less reliable. We plot the CDN delivery length of each individual user in Figure 7(b). We observe that U1 and U4 have the same delivery lengths in both scenarios, while U2 and U3 experience longer paths with CSC. The aggregated distances for the two scenarios are 10.41 Kmiles and 11.42 Kmiles, respectively, or 9.70% of increase. These results show that some users’ experience can be slightly negatively affected by CSC, which is expected, as apparently the default layered star-like network results in shortest paths for each individual user. Note that CDN providers often optimize the CDN delivery paths (i.e., paths between CDN servers). For instance, Akamai [1] and Internap [3] optimize their networks with patented techniques [7], [8]. Therefore, it is important to realize that the
- 6. 0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00 S1 S2 S3 S4 Total Default CSC (a) CDN Transit Cost 0 2 4 6 8 10 12 U1 U2 U3 U4 Total Default CSC (b) Individual Delivery Paths Fig. 7. CDN transit cost and user experience user-experienced performance will not be affected significantly even with longer delivery path. D. Money Talks Taking a more direct business perspective, we now compare the transit cost with respect to the pricing of bandwidth usage. Depending on subscription packages, CDN providers may need to pay ISPs for the bandwidth used. We assume each live stream is 3Mbps. In the above scenario where only 4 streaming servers are delivering the live stream, the saved bandwidth per day would be 0.07 TB*Kmiles (or 25.35 TB*KMiles per year). With 3000 streams, the saved bandwidth would be 210 TB*Kmiles (or 76.04 PB * Kmiles per year). Though the exact CDN transit pricing varies across time and subscription packages, we attempt to obtain concrete cost values by simply assuming the transit cost of 0.10 per GB/Kmile. With such a cost, CSC can help save $7.60 Million per year with 3000 streams, or about $2.53K per stream. VI. RELATED WORK Content Delivery Networks (CDNs) have been carried out by various providers to expedite the web access [1]–[5]. The techniques used by CDNs for delivering conventional web contents are explained in related writings [9], [10]. Despite the popularity and pervasiveness of CDNs, many research problems and system-building challenges persist for optimiz- ing CDN infrastructure and addressing challenges associated supporting various types of applications. For instance, as we demonstrated in this work, how to efficiently support the application of live streaming with CDNs deserves more study. Though various network architectures have been proposed and utilized for different deployment scenarios with the rapid development of Internet technology [11]–[14], CDN providers typically apply layered structure (e.g., ingest-layer, origin- layer and edge-layer) due to the caching-property of delivering static web contents tracing back to Day-1 of CDN industry. Realizing that CDNs and P2P can complement each other, many research efforts also attempt to integrate these two realms into one [15]. Unlike these works that combine the merits of both CDNs and P2P, our work takes an inside perspective and attempts to refine CDN delivery infrastructure. Live streaming has been studied and analyzed from various perspectives [16]–[18]. The unique properties of live stream- ing, coupled with CDN-assisted delivery, justifies a specialized design of CDN infrastructure that specifically serves live streaming and saves CDN transit cost. To our best knowledge, this work is the first to consider and address the problem of saving transit cost for delivering live streaming with CDNs. VII. CONCLUSION In this work, we propose a flat CDN infrastructure for delivering live streaming with CDNs. Referred to as CSC, the new infrastructure can greatly reduce CDN transit cost without significantly affecting users’ experience. REFERENCES [1] “Akamai technologies,” http://www.akamai.com/. [2] “At&t inc.” http://www.att.com/. [3] “Internap network services corporation,” http://www.internap.com/. [4] “Level 3 communications, llc.” http://www.level3.com/. [5] “Limelight networks,” http://www.limelightnetworks.com/. [6] “Bind geodns,” http://www.caraytech.com/geodns/. [7] Internap-MIRO, “Method and system for optimizing routing through multiple available internet route providers,” 2005. [8] A. Patent, “Optimal route selection in a content delivery network,” United States Patent 7274658, 2007. [9] K. Park, W. W. (editors, H. Kung, and C. Wu, “Content networks: Taxonomy and new approaches,” 2002. [10] D. C. Verma, S. Calo, and K. Amiri, “Policy based management of content distribution networks,” IEEE Network Magazine, vol. 16, pp. 34–39, 2002. [11] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, “Chord: A scalable peer-to-peer lookup service for internet applications,” in SIGCOMM ’01: Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications, San Diego, CA, USA, 2001. [12] A. I. T. Rowstron and P. Druschel, “Pastry: Scalable, decentralized object location, and routing for large-scale peer-to-peer systems,” in Middleware ’01: Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms Heidelberg, London, UK, 2001. [13] S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Schenker, “A scalable content-addressable network,” in SIGCOMM ’01: Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications, San Diego, CA, USA, 2001. [14] I. Stoica, D. Adkins, S. Zhuang, S. Shenker, and S. Surana, “Internet indirection infrastructure,” IEEE/ACM Trans. Netw., vol. 12, no. 2, pp. 205–218, 2004. [15] H. Yin, X. Liu, T. Zhan, V. Sekar, F. Qiu, C. Lin, H. Zhang, and B. Li, “Livesky: Enhancing cdn with p2p,” ACM Trans. Multimedia Comput. Commun. Appl., vol. 6, pp. 16:1–16:19, August 2010. [16] K. Sripanidkulchai, B. Maggs, and H. Zhang, “An analysis of live streaming workloads on the internet,” in Proceedings of the 4th ACM SIGCOMM conference on Internet measurement, ser. IMC ’04, 2004. [17] J. He, A. Chaintreau, and C. Diot, “A performance evaluation of scalable live video streaming with nano data centers,” Comput. Netw., vol. 53, pp. 153–167, February 2009. [18] C. Vicari, C. Petrioli, and F. L. Presti, “Dynamic replica placement and traffic redirection in content delivery networks,” SIGMETRICS Perform. Eval. Rev., vol. 35, December 2007.