Internet DRAFT - draft-famaey-cdni-has-experiments
draft-famaey-cdni-has-experiments
Content Delivery Networks J. Famaey
Interconnection Working Group S. Latre
Internet-Draft UGent - iMinds
Intended status: Informational January 24, 2013
Expires: July 28, 2013
Experiments on HTTP Adaptive Streaming over interconnected Content
Delivery Networks
draft-famaey-cdni-has-experiments-01
Abstract
This document reports experimental results on the delivery of HTTP
Adaptive Streaming (HAS) content over interconnected Content Delivery
Networks (CDNs). Specifically, the implications that CDN request
routing between CDNs and HTTP redirection have on the quality of
delivered HAS content are investigated.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 28, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Famaey & Latre Expires July 28, 2013 [Page 1]
Internet-Draft Experiments on HAS and CDNI January 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Experimental Setup . . . . . . . . . . . . . . . . . . . . . . 3
3. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Congested Scenario . . . . . . . . . . . . . . . . . . . . 6
3.2. Uncongested Scenario . . . . . . . . . . . . . . . . . . . 9
3.3. Influence of Segment Duration . . . . . . . . . . . . . . 11
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Normative References . . . . . . . . . . . . . . . . . . . 14
6.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Famaey & Latre Expires July 28, 2013 [Page 2]
Internet-Draft Experiments on HAS and CDNI January 2013
1. Introduction
HTTP Adaptive Streaming (HAS) refers to a set of novel streaming
approaches, which deliver streaming media content over the HTTP
protocol. The content is split into chunks, offered in several
quality layers. This allows the client to dynamically adapt the
requested quality, based on available network resources and device
capabilities. Delivering HAS content across multiple interconnected
CDNs introduces some new opportunities and challenges. Specifically,
it becomes possible to distribute the chunks of a single HAS content
stream across servers deployed on multiple CDNs, based on chunk
popularity, Quality of Service requirements, resource availability,
costs or other factors.
Every HAS content stream is accompanied by a Manifest File, which
lists the chunks of each quality layer and specifies their location
in the form of a URL. As stated in [I-D.brandenburg-cdni-has],
several alternative methods exist for specifying chunk locations:
o Relative URLs: The URLs specified in the Manifest File are
relative to the Manifest File's location and thus all located on
the same surrogate.
o Absolute URLs with Redirection: The Manifest File specifies the
fully qualified URL of each chunk. These URLs, however, direct
the client towards the CDN's request routing node, which in turn
uses HTTP redirection to send the client to the surrogate hosting
the actual chunk.
o Absolute URLs without Redirection: The URL points directly to the
surrogate hosting the chunk, effectively allowing the client to
circumvent the CDN request routing process.
This document aims to evaluate and compare different request routing
policies for HAS content, derived from these addressing mechanisms,
that can be used in federated CDN scenarios.
2. Experimental Setup
The scenario used as a basis for the experiments consists of two
interconnected CDNs. The downstream CDN is located close to the end-
user (e.g., a telco CDN), while the upstream CDN is positioned
further (e.g., in the core Internet). The upstream CDN is assumed to
be the main storage facility of the original content. As such, it
hosts the Manifest file but can offload content chunks to one or more
downstream CDNs. Figure 1 graphically depicts the scenario and lists
the parameters that were varied in the course of the experiments.
Famaey & Latre Expires July 28, 2013 [Page 3]
Internet-Draft Experiments on HAS and CDNI January 2013
The upstream CDN request router, upstream CDN content server,
downstream CDN request router and downstream CDN content server are
depicted as uRR, uCS, dRR and dCS, respectively. During the
experiments, five parameters were varied: the one-way Internet delay
ID, the one-way downstream CDN delay DD, the per-client bandwidth B,
the HAS client buffer size P and the HAS segment duration S. The
bandwidth on all other network links was set to 100 Mbps, while the
one-way network delay was set to 5 ms. The round trip time (RTT)
between two nodes can be calculated as the sum of the one-way delays
of the links on the path between them, multiplied by two. In the
performed experiments, the client and dRR/dCS are separated by three
links, resulting in a RTT of (2 * 5 + DD) * 2 = (20 + 2 DD) ms. On
the other hand, the client and uRR/uCS are 5 links apart, resulting
in a RTT of (4 * 5 + ID) * 2 = (40 + 2 ID) ms. Note that the figure
presents a high level, simplified view of the network topology and
does not show all individual network links and routers.
Additionally, the processing delay on the CDN surrogates is not taken
into account, as it is assumed to be negligible compared to the
network delay.
+---+ +---+ |B Mbps
+---+ +---+ ID ms delay |dRR| |dCS| |bandwidth
|uRR| |uCS| <-------------> +---+ +---+ |
+---+ +---+ DD ms | | | |P second
| | delay | | | |buffer
,--,--,--. ,--,--. ,--,--,--. | v
,-' `-. ,-' `-. ,-' `-. v +------+
( Upstream CDN )===( Internet )===( Downstream CDN )===|Client|
`-. ,-' `-. ,-' `-. ,-' +------+
`--'--'--' `--'--' `--'--'--'
Figure 1: Evaluation scenario and parameters
Three alternative request routing policies are evaluated and
compared:
o UpstreamRR: The Manifest File points to the uRR for every chunk.
If the chunk is located within the upstream CDN's network, the uRR
sends the client a HTTP redirect request to point it to the
correct uCS. Otherwise, the uRR redirects the client to dRR,
which in turn redirects it to the correct dCS.
o DirectRR: The Manifest File immediately points to the correct
request router, which redirects the client to the correct content
server. This policy thus allows the client to circumvent going
via the upstream CDN's network if the chunk is located downstream.
Famaey & Latre Expires July 28, 2013 [Page 4]
Internet-Draft Experiments on HAS and CDNI January 2013
o DirectCS: The Manifest File immediately points to the correct
content server, which allows the client to download segments
without being redirected. Compared to the DirectRR policy, the
indirection of contacting the dRR is avoided.
The UpstreamRR policy can be seen as the traditional CDN-I approach,
where clients always contact the original CDN and HTTP redirection is
used to point them to interconnected CDNs when necessary. It does
not require any Manifest File rewriting. Additionally, the upstream
CDN does not need any detailed information about chunk locations, as
it only needs to redirect clients to the downstream request router.
The DirectRR and DirectCS policies are more complex, as they require
the upstream CDN to rewrite the original Manifest File.
Additionally, when using the DirectCS policy, the downstream CDN
either needs to share detailed chunk location information with the
upstream CDN or the interconnected CDNs need to collaborate in
creating the Manifest File.
The experiments evaluate a scenario where a single client downloads a
200 second video clip (split into 200/S segments). The first half is
hosted by the downstream CDN, while the second half is hosted by the
upstream CDN. The constant bitrate (CBR) video is available in 3
qualities, with bitrates 500 kbps, 1 Mbps and 2 Mbps respectively.
As the end-user Quality of Experience (QoE) depends on several
factors, multiple evaluation metrics are used in the comparison:
o Average played quality: The played quality layer, averaged over
all chunks and specified in terms of bitrate. This is expressed
in megabits per second (Mbps), representing the bandwidth required
for downloading the played quality layers.
o Total buffer starvation time: The accumulated time during which
the client needs to rebuffer the chunks (excluding the original
start-up). A rebuffering occurs when a chunk is not available at
the client, while it is already required for decoding. This leads
to frame freezes, as the client needs to wait for the next chunk
to arrive, which significantly reduces QoE.
o Start-up delay: The time between the initial HTTP request for the
first chunk, performed by the client, and the time when the chunk
actually starts playing.
All reported results were obtained using the NS-3 simulation
environment [ns3] in combination with the Network Simulation Cradle
(NSC) [nsc]. NS-3 is a discrete-event network simulator for Internet
systems. NSC allows NS-3 to interface directly with the kernel's TCP
implementation, generating more accurate and realistic results. The
Famaey & Latre Expires July 28, 2013 [Page 5]
Internet-Draft Experiments on HAS and CDNI January 2013
used HAS client rate adaptation algorithm is based on the first
version of the client algorithm incorporated in Microsoft's
SmoothStreaming client. The source code of this algorithm can be
retrieved from CodePlex [msscode].
3. Results
This section lists and discusses experimental results on the average
played video quality, total buffer starvation time and the start-up
delay. First, the effects of several parameters on the QoE metrics
are studied, both in a congested and an uncongested network. Second,
the influence of segment duration is evaluated.
3.1. Congested Scenario
The congested scenario considers a client-side bandwidth B of 1Mbps,
which, due to protocol overhead allows only the lowest 500kbps
quality to be streamed. As such, this section focuses on a
comparison of the buffer starvation time and start-up delay. The
segment duration S is fixed at 2s. The results on buffer starvation
as a function of one-way Internet delay ID, one-way downstream CDN
delay DD and client buffer size P are shown in Figure 2. The
starvation time is shown separately for the first 50 segments
downloaded from dCS (Dws) and the latter 50 downloaded from uCS
(Ups). The results on start-up delay are depicted in Figure 3 as a
function of delays ID and DD only, as they are unaffected by the
buffer size P.
In general, the results depicted in Figure 2 clearly show that
minimising the number of HTTP redirects benefits the QoE
significantly, both for segments hosted at the downstream as well as
the upstream CDN. Specifically, several observations can be made
based on the depicted results. First, as expected, DirectCS and
DirectRR are not influenced by an increasing Internet delay for
downstream segments, as they completely circumvent the upstream CDN
in this case. In contrast, when using the traditional UpstreamRR
approach buffer starvations start occurring at a one-way Internet
delay of as low as 100ms if the downstream CDN delay is 50ms or
higher. If the downstream delay is low, then starvations start
occurring at a 200ms Internet delay. Second, for upstream segments,
DirectRR and DirectCS are also negatively impacted by an increasing
Internet delay. However, DirectCS is significantly less influenced
by it than DirectRR, as it circumvents DirectRR's redirect from uRR
to uCS. Third, increasing the buffer size clearly helps reducing
buffer starvations in the upstream scenario for DirectRR and
DirectCS. This is due to the fact that the client can fill its
buffer when downloading the first 50 segments from dCS. This set of
Famaey & Latre Expires July 28, 2013 [Page 6]
Internet-Draft Experiments on HAS and CDNI January 2013
backup segments subsequently allows the client to temporarily
maintain desirable QoE levels under high RTT. When using UpstreamRR,
the client cannot fill its buffer during the initial phase, due to
the larger number of redirects, and a larger buffer therefore does
not improve results.
+------+------+------+-----------------------------------------------+
| | | | Total buffer starvation time (s) |
| P | DD | ID +---------------+---------------+---------------+
| | | | UpstreamRR | DirectRR | DirectCS |
| (s) | (ms) | (ms) +-------+-------+-------+-------+-------+-------+
| | | | Dws | Ups | Dws | Ups | Dws | Ups |
+------+------+------+-------+-------+-------+-------+-------+-------+
| | | 50 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| | +------+-------+-------+-------+-------+-------+-------+
| | 5 | 100 | 0.0 | 0.1 | 0.0 | 0.0 | 0.0 | 0.0 |
| | +------+-------+-------+-------+-------+-------+-------+
| | | 200 | 10.3 | 34.4 | 0.0 | 30.4 | 0.0 | 10.2 |
| 6 +------+------+-------+-------+-------+-------+-------+-------+
| | | 50 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| | +------+-------+-------+-------+-------+-------+-------+
| | 50 | 100 | 5.5 | 3.8 | 0.0 | 0.0 | 0.0 | 0.0 |
| | +------+-------+-------+-------+-------+-------+-------+
| | | 200 | 18.6 | 34.5 | 0.0 | 30.4 | 0.0 | 10.2 |
+------+------+------+-------+-------+-------+-------+-------+-------+
| | | 50 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| | +------+-------+-------+-------+-------+-------+-------+
| | 5 | 100 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| | +------+-------+-------+-------+-------+-------+-------+
| | | 200 | 10.4 | 34.4 | 0.0 | 12.4 | 0.0 | 0.0 |
| 24 +------+------+-------+-------+-------+-------+-------+-------+
| | | 50 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| | +------+-------+-------+-------+-------+-------+-------+
| | 50 | 100 | 5.5 | 3.8 | 0.0 | 0.0 | 0.0 | 0.0 |
| | +------+-------+-------+-------+-------+-------+-------+
| | | 200 | 18.6 | 34.4 | 0.0 | 13.5 | 0.0 | 0.0 |
+------+------+------+-------+-------+-------+-------+-------+-------+
Figure 2: The total buffer starvation time as a function of client
buffer size P and one-way Internet delay ID and one-way downstream
CDN delay DD; for B = 1Mbps and S = 2s
Famaey & Latre Expires July 28, 2013 [Page 7]
Internet-Draft Experiments on HAS and CDNI January 2013
+------+------+--------------------------------------+
| | | Start-up delay (s) |
| ID + DD +------------+------------+------------+
| (ms) | (ms) | UpstreamRR | DirectRR | DirectCS |
+------+------+------------+------------+------------+
| | 5 | 2.11 | 1.81 | 1.72 |
| 50 +------+------------+------------+------------+
| | 50 | 2.92 | 2.63 | 2.37 |
+------+------+------------+------------+------------+
| | 5 | 2.31 | 1.81 | 1.72 |
| 100 +------+------------+------------+------------+
| | 50 | 3.12 | 2.63 | 2.37 |
+------+------+------------+------------+------------+
| | 5 | 2.71 | 1.81 | 1.72 |
| 200 +------+------------+------------+------------+
| | 50 | 3.52 | 2.63 | 2.37 |
+------+------+------------+------------+------------+
Figure 3: The start-up delay as a function of one-way Internet delay
ID and one-way downstream CDN delay DD; for B = 1Mbps, S = 2s and P =
6s
The results in Figure 3 clearly show that the start-up delay is
linearly proportional to the delay between the client and server.
This explains the two evolutions visible in the table. First, for
segments hosted at the downstream CDN, the start-up delay for
UpstreamRR increases as a function of the one-way Internet delay ID,
while DirectRR and DirectCS are unaffected. Second, the start-up
delay for all routing policies increases as a function of the one-way
downstream delay DD. Finally, due to the lower redirection delay of
DirectCS compared to DirectRR, the DirectCS start-up delay is
slightly lower. Note that this start-up delay occurs whenever the
buffer needs to be flushed. As such, this not only happens when a
client initiates a session, but also for example when switching
channels in Internet TV scenarios or skipping to another part of a
movie in a Video on Demand scenario.
In summary, it was shown that in congested scenarios, using the
DirectRR or DirectCS routing policies can significantly reduce the
amount of client-side buffer starvation compared to using the
traditional UpstreamRR policy, when downloading HAS segments from the
downstream CDN. Additionally, the use of DirectCS is beneficial in
terms of buffer starvations compared to DirectRR and UpstreamRR when
downloading segments from the upstream CDN. Although a larger buffer
size was shown to help in temporarily overcoming the negative effects
of high network latency, this only helps if a client can first fill
its buffer by downloading segments with low latency. Finally, it was
shown that the start-up delay is linearly proportional to the total
Famaey & Latre Expires July 28, 2013 [Page 8]
Internet-Draft Experiments on HAS and CDNI January 2013
RTT, both caused by network latency to the content server, as well as
redirection delay. As such, the DirectRR and DirectCS start-up delay
is unaffected by the Internet delay when streaming from the
downstream CDN, while that of UpstreamRR is not. Moreover, DirectCS
has a lower start-up delay than DirectRR.
3.2. Uncongested Scenario
The uncongested scenario considers a client-side bandwidth B of
5Mbps, which is sufficient to download the highest 2Mbps quality
layer stream. As such, this section does consider the delivered
video quality. As buffer starvation and start-up delay results were
already discussed in much detail in the previous section, and they
show similar trends in the uncongested scenario, they are omitted
here. The segment duration S is once again fixed at 2s. The results
on average played video quality as a function of one-way Internet
delay ID, one-way downstream CDN delay DD and client buffer size P
are shown in Figure 4. The quality is shown separately for the first
50 segments downloaded from dCS (Dws) and the latter 50 downloaded
from uCS (Ups).
The results in Figure 4 prove that an increased number of
redirections significantly impacts video quality, even for a
relatively low RTT. Specifically, the results show that UpstreamRR
achieves a significantly lower quality than DirectRR and DirectCS for
segments hosted at the downstream CDN for all depicted parameter
combinations. Additionally, as expected, the delivered video quality
when using UpstreamRR is inversely proportional to the Internet delay
ID. In contrast, DirectRR and DirectCS are unaffected. In addition
to the quality difference for segments hosted at the downstream CDN,
there also are some remarkable differences for upstream CDN segments.
Although UpstreamRR and DirectRR exhibit the same behaviour when
downloading segments from the upstream CDN, they do show a difference
in video quality. This is due to suboptimal decision making by the
MSS client algorithm when switching servers. The UpstreamRR policy
often results in a lower quality being requested for the downstream
segments. However, when switching to the upstream CDN, the algorithm
might not always decide to increase the quality, even if this would
in theory be possible. This behaviour is caused by the way clients
estimate the available throughput, which does not take into account
multiple servers. In contrast, when using DirectRR the client is
already downloading a higher quality from the dCDN, and will not
change this when switching to the uCDN. Consequently, suboptimal
decisions of the client algorithm, as a consequence of server
switching, can lead to unexpected differences between UpstreamRR and
DirectRR. Finally, the results show that increasing the buffer size
leads to a higher delivered video quality in almost all cases.
Famaey & Latre Expires July 28, 2013 [Page 9]
Internet-Draft Experiments on HAS and CDNI January 2013
+------+------+------+-----------------------------------------------+
| | | | Average played quality (Mbps) |
| P | DD | ID +---------------+---------------+---------------+
| | | | UpstreamRR | DirectRR | DirectCS |
| (s) | (ms) | (ms) +-------+-------+-------+-------+-------+-------+
| | | | Dws | Ups | Dws | Ups | Dws | Ups |
+------+------+------+-------+-------+-------+-------+-------+-------+
| | | 50 | 0.50 | 0.50 | 1.93 | 1.14 | 1.95 | 1.27 |
| | +------+-------+-------+-------+-------+-------+-------+
| | 5 | 100 | 0.50 | 0.50 | 1.93 | 1.02 | 1.95 | 1.03 |
| | +------+-------+-------+-------+-------+-------+-------+
| | | 200 | 0.50 | 0.50 | 1.93 | 0.53 | 1.95 | 0.54 |
| 6 +------+------+-------+-------+-------+-------+-------+-------+
| | | 50 | 0.50 | 0.50 | 0.97 | 1.00 | 0.98 | 1.00 |
| | +------+-------+-------+-------+-------+-------+-------+
| | 50 | 100 | 0.50 | 0.50 | 0.97 | 0.51 | 0.98 | 0.52 |
| | +------+-------+-------+-------+-------+-------+-------+
| | | 200 | 0.50 | 0.50 | 0.97 | 0.51 | 0.98 | 0.52 |
+------+------+------+-------+-------+-------+-------+-------+-------+
| | | 50 | 1.64 | 2.00 | 1.93 | 2.00 | 1.95 | 2.00 |
| | +------+-------+-------+-------+-------+-------+-------+
| | 5 | 100 | 0.85 | 1.00 | 1.93 | 1.04 | 1.95 | 0.98 |
| | +------+-------+-------+-------+-------+-------+-------+
| | | 200 | 0.50 | 0.50 | 1.93 | 0.69 | 1.95 | 0.66 |
| 24 +------+------+-------+-------+-------+-------+-------+-------+
| | | 50 | 0.50 | 0.50 | 1.38 | 2.00 | 1.40 | 2.00 |
| | +------+-------+-------+-------+-------+-------+-------+
| | 50 | 100 | 0.50 | 0.50 | 1.38 | 1.01 | 1.40 | 0.98 |
| | +------+-------+-------+-------+-------+-------+-------+
| | | 200 | 0.50 | 0.50 | 1.38 | 0.65 | 1.40 | 0.66 |
+------+------+------+-------+-------+-------+-------+-------+-------+
Figure 4: The average played quality as a function of client buffer
size P, one-way Internet delay ID and one-way downstream CDN delay
DD; for B = 5Mbps and S = 2s
In summary, the merits of DirectRR and DirectCS compared to
UpstreamRR in uncongested networks were clearly shown. In addition
to a reduction in buffer starvations and start-up delay, the DirectRR
and DirectCS policies also result in an increased delivered video
quality when enough bandwidth is available. Specifically, when using
UpstreamRR and streaming content from the downstream CDN, the video
quality is significantly impaired by an increase in Internet delay,
while DirectRR and DirectCS are unaffected. Additionally, due to the
fact that HAS client algorithms are unoptimised for delivery of a
single stream from multiple servers, UpstreamRR additionally suffers
a reduction in video quality compared to DirectRR for segments served
from the upstream CDN in some scenarios.
Famaey & Latre Expires July 28, 2013 [Page 10]
Internet-Draft Experiments on HAS and CDNI January 2013
3.3. Influence of Segment Duration
Previous sections only considered a short segment duration S of 2s.
Although this value is widely used, by for example Microsoft
SmoothStreaming-based services, others, such as Apple HTTP Live
Streaming, generally recommend longer segment durations. This
section evaluates the effect of segment duration S on the average
played quality as well as the start-up delay in an uncongested
scenario with a client-side bandwidth B of 5Mbps. As results showed
that the used HAS algorithm performs poorly if the buffer fits only
two segments or less and a segment duration of up to 12s is
considered, a buffer size P of 36s is used. The results on average
played quality as a function of segment duration S, one-way Internet
delay ID and one-way downstream CDN delay DD are shown in Figure 5.
The quality is shown separately for the first 50 segments downloaded
from dCS (Dws) and the latter 50 downloaded from uCS (Ups). The
results on start-up delay are depicted in Figure 6 as a function of
S, ID and DD.
The results depicted in Figure 5 clearly prove that increasing the
segment duration greatly improves performance of the three routing
policies for large delays. If both ID and DD are large enough, it
evens out performance of the three policies completely, removing the
negative effects of redirects. This is obviously due to the fact
that increasing the segment duration, decreases the number of
requests and thus the relative delay introduced by redirects. On the
other hand, longer segment durations result in lower average quality
when the delay is very low (i.e., ID = 50ms, DD = 5ms). This is
because increasing the segment duration results in a proportional
increase in convergence time to the optimal video quality.
Famaey & Latre Expires July 28, 2013 [Page 11]
Internet-Draft Experiments on HAS and CDNI January 2013
+------+------+------+-----------------------------------------------+
| | | | Average played quality (Mbps) |
| S | DD | ID +---------------+---------------+---------------+
| | | | UpstreamRR | DirectRR | DirectCS |
| (s) | (ms) | (ms) +-------+-------+-------+-------+-------+-------+
| | | | Dws | Ups | Dws | Ups | Dws | Ups |
+------+------+------+-------+-------+-------+-------+-------+-------+
| | | 50 | 1.95 | 2.00 | 1.93 | 2.00 | 1.95 | 2.00 |
| | +------+-------+-------+-------+-------+-------+-------+
| | 5 | 100 | 1.59 | 1.46 | 1.93 | 1.46 | 1.95 | 1.16 |
| | +------+-------+-------+-------+-------+-------+-------+
| | | 200 | 1.15 | 0.75 | 1.93 | 0.74 | 1.95 | 0.72 |
| 2 +------+------+-------+-------+-------+-------+-------+-------+
| | | 50 | 1.43 | 2.00 | 0.96 | 1.00 | 1.16 | 2.00 |
| | +------+-------+-------+-------+-------+-------+-------+
| | 50 | 100 | 0.81 | 1.00 | 0.96 | 1.00 | 1.16 | 1.16 |
| | +------+-------+-------+-------+-------+-------+-------+
| | | 200 | 0.50 | 0.50 | 0.96 | 0.70 | 1.16 | 0.72 |
+------+------+------+-------+-------+-------+-------+-------+-------+
| | | 50 | 1.83 | 2.00 | 1.83 | 2.00 | 1.83 | 2.00 |
| | +------+-------+-------+-------+-------+-------+-------+
| | 5 | 100 | 1.72 | 2.00 | 1.83 | 2.00 | 1.83 | 2.00 |
| | +------+-------+-------+-------+-------+-------+-------+
| | | 200 | 1.72 | 2.00 | 1.83 | 2.00 | 1.83 | 2.00 |
| 12 +------+------+-------+-------+-------+-------+-------+-------+
| | | 50 | 1.61 | 2.00 | 1.61 | 2.00 | 1.61 | 2.00 |
| | +------+-------+-------+-------+-------+-------+-------+
| | 50 | 100 | 1.61 | 2.00 | 1.61 | 2.00 | 1.61 | 2.00 |
| | +------+-------+-------+-------+-------+-------+-------+
| | | 200 | 1.61 | 2.00 | 1.61 | 2.00 | 1.61 | 2.00 |
+------+------+------+-------+-------+-------+-------+-------+-------+
Figure 5: The average played quality as a function of segment
duration S, one-way Internet delay ID and one-way downstream CDN
delay DD; for B = 5Mbps and P = 36s
Although using longer segment durations is an effective way to
increase the video quality in face of redirects with high latency, it
also has several disadvantages. As shown in Figure 6 the start-up
delay increases significantly as a function of the segment duration.
This is the case for all routing policies. Additionally, long
segment durations are usually a poor choice in combination with live
services, as they lead to significant lag of the streaming session
compared to the live time.
Famaey & Latre Expires July 28, 2013 [Page 12]
Internet-Draft Experiments on HAS and CDNI January 2013
+-----+------+------+--------------------------------------+
| | | | Start-up delay (s) |
| S | ID + DD +------------+------------+------------+
| (s) | (ms) | (ms) | UpstreamRR | DirectRR | DirectCS |
+-----+------+------+------------+------------+------------+
| | | 5 | 0.77 | 0.48 | 0.40 |
| | 50 +------+------------+------------+------------+
| | | 50 | 1.56 | 1.26 | 1.00 |
| 2 +------+------+------------+------------+------------+
| | | 5 | 1.38 | 0.48 | 0.40 |
| | 200 +------+------------+------------+------------+
| | | 50 | 2.16 | 1.26 | 1.00 |
+-----+------+------+------------+------------+------------+
| | | 5 | 1.81 | 1.51 | 1.43 |
| | 50 +------+------------+------------+------------+
| | | 50 | 3.08 | 2.80 | 2.54 |
| 12 +------+------+------------+------------+------------+
| | | 5 | 2.41 | 1.51 | 1.43 |
| | 200 +------+------------+------------+------------+
| | | 50 | 3.68 | 2.80 | 2.54 |
+-----+------+------+------------+------------+------------+
Figure 6: The start-up delay as a function of segment duration S,
one-way Internet delay ID and one-way downstream CDN delay DD; for B
= 5Mbps and P = 36s
In summary, results showed that increasing the HAS segment duration
can help in overcoming the reduced video quality that occurs when
using simple Inter-CDN routing policies, such as UpstreamRR.
Nevertheless, long segment durations also have significant
disadvantages, such as slower convergence to the optimal quality, an
increased start-up delay and greater session lag in live scenarios.
This makes them unsuitable in many use-cases, such as live or
channel-switching intensive services.
4. Conclusion
In this document, we proposed, evaluated and compared several
policies for routing requests and retrieving HAS content chunks
distributed across multiple interconnected CDNs. Concretely, the
traditional policy, herein called UpstreamRR, in which the original
CDN's request router dynamically redirects the end-users towards the
CDN currently hosting the requested content, is compared to two novel
policies, called DirectRR and DirectCS. These novel policies employ
HAS Manifest File rewriting to directly point end-users to the
correct CDN (DirectRR) or even the correct content server (DirectCS).
Famaey & Latre Expires July 28, 2013 [Page 13]
Internet-Draft Experiments on HAS and CDNI January 2013
A thorough evaluation, using an open source implementation of the
Microsoft Smooth Streaming client algorithm and based on NS-3
simulation results, was conducted. It shows that the end-user QoE
suffers greatly as a consequence of the HTTP redirects that occur
when employing the standard UpstreamRR policy. Specifically, it was
shown that when downloading segments from the downstream CDN,
DirectRR and DirectCS result in a much lower buffer starvation rate
and start-up delay, as well as an increased video quality compared to
UpstreamRR. Additionally, DirectCS significantly outperforms the
other two strategies in terms of buffer starvation rate and start-up
delay for segments downloaded from the upstream CDN. Finally, the
evaluation showed that increasing the segment duration can negate the
negative effects of redirects on video quality when using the
UpstreamRR policy. However, it also leads to increased start-up
delay and slower convergence to the optimal quality.
In summary, these results prove the need for advanced request routing
mechanisms, as well as extensive cooperation between interconnected
CDNs, to be able to satisfy end-user quality requirements of state-
of-the-art HAS-based services. Additionally, the results show the
merits of the more complex DirectCS policy compared to the easier to
implement DirectRR.
5. Security Considerations
Not applicable.
6. References
6.1. Normative References
[I-D.brandenburg-cdni-has]
Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung,
"Models for adaptive-streaming-aware CDN Interconnection",
draft-brandenburg-cdni-has-03 (work in progress),
July 2012.
6.2. Informative References
[msscode] "Microsoft's SmoothStreaming rate adaptation algorithm v1
source code", <https://slextensions.svn.codeplex.com/svn/
trunk/SLExtensions/AdaptiveStreaming/>.
[ns3] "NS-3 discrete event network simulator",
<http://www.nsnam.org/>.
Famaey & Latre Expires July 28, 2013 [Page 14]
Internet-Draft Experiments on HAS and CDNI January 2013
[nsc] "Network Simulation Cradle",
<http://research.wand.net.nz/software/nsc.php>.
Authors' Addresses
Jeroen Famaey
Ghent University - iMinds
Gaston Crommenlaan 8/201
Ghent 9050
Belgium
Phone: +32 9 331 49 38
Email: jeroen.famaey@intec.ugent.be
Steven Latre
Ghent University - iMinds
Gaston Crommenlaan 8/201
Ghent 9050
Belgium
Phone: +32 9 331 49 88
Email: steven.latre@intec.ugent.be
Famaey & Latre Expires July 28, 2013 [Page 15]
