Internet DRAFT - draft-krishnan-cdni-tm-has
draft-krishnan-cdni-tm-has
CDNI R. Krishnan
Internet Draft Brocade Communications
Intended status: Informational B. Khasnabish
Expires: January 2013 ZTE Corporation
July 30, 2012
Traffic management models for http adaptive-streaming-aware CDN
Interconnection
draft-krishnan-cdni-tm-has-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
Krishnan, et al. Expires January 30, 2013 [Page 1]
Internet-Draft TM Models for HAS aware CDN Interconnection July 2012
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on Fail 30, 0000.
Copyright Notice
Copyright (c) 0000 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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.
Abstract
This document presents thoughts on the traffic management aspects of
supporting HTTP Adaptive Streaming technologies in CDN
Interconnection scenarios. Our intent is to recommend traffic
management techniques which can offer the best adaptive streaming
performance over CDN interconnections.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................3
3. CDNi interface bandwidth challenges............................3
4. CDNi interface traffic management..............................4
4.1. WRED Configuration Example................................5
4.1.1. Router buffering and queueing recommendations........7
Krishnan, et al. Expires January 30, 2013 [Page 2]
Internet-Draft TM Models for HAS aware CDN Interconnection July 2012
4.1.2. IP DSCP and Queue size mapping for IPv4 traffic
recommendations.............................................7
5. References.....................................................8
5.1. Normative References......................................8
5.2. Informative References....................................8
1. Introduction
HTTP Adaptive Streaming (HAS) is an umbrella term for various HTTP-
based streaming technologies that allow a client to adaptively switch
between multiple bitrates depending on current network conditions. A
defining aspect of HAS is that, since it is based on HTTP, it is a
pull-based mechanism, with a client actively requesting content
segments, instead of the content being pushed to the client by a
server. The underlying protocol used by HTTP is TCP/IP. This document
presents the challenges in CDNi interface bandwidth provisioning,
given the heavy asymmetric usage of the network between peak and
quiet hours. The document [I-D.brandenburg-cdni-has-03] recommends
various models for adaptive streaming aware CDN interconnection. This
document complements the above document by recommending traffic
management techniques which can offer the best adaptive streaming
performance over CDN interconnections during hours of congestion.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This document reuses the terminology defined in:
[I-D.ietf-cdni-problem-statement-06],
[I-D.ietf-cdni-requirements-03],
[I-D.ietf-cdni-framework-00], and
[I-D.ietf-cdni-use-cases-08].
3. CDNi interface bandwidth challenges
Typically, the interface between CDNs is a long-haul backbone network
where bandwidth is premium. The bandwidth needs of HAS is directly
proportional to the number of active end users who are streaming
video. The bandwidth requirements of HAS are quite asymmetric, with
the bandwidth usage during peak family hours is substantially higher
as compared to the normal hours. Caching in the CDN-I alleviates this
Krishnan, et al. Expires January 30, 2013 [Page 3]
Internet-Draft TM Models for HAS aware CDN Interconnection July 2012
to a certain degree, but we could have network congestion in the
following scenarios 1) During peak hours, in a pull model caching,
the first copy of many HAS streams would be delivered. 2) Long-tail
personalized content, which is not amenable to caching, is desired by
the end user. A naive solution would be to dimension the CDNi
bandwidth for the peak hour usage and projected user growth which can
lead to an expensive backbone network infrastructure. By using
traffic management techniques described below, this issue network
congestion issue can be alleviated by to a great degree and the
backbone network need not be dimensioned for peak usage.
4. CDNi interface traffic management
The CDNi interface links, which are typically long haul, have much
lower bandwidth as compared to the links in the CDN. As discussed in
the previous section, there is potential for congestion in the CDNi
interface links especially during peak hours. The underlying protocol
used by HAS is TCP/IP. In the standard router configuration, the
default congestion avoidance behavior for TCP/IP traffic is tail
drop. Tail drop causes global synchronization of TCP/IP hosts or in
effect the end users of HAS. Global synchronization occurs as waves
of congestion crest only to be followed by troughs during which the
CDNi interface link(s) are not fully utilized. Global synchronization
of TCP hosts, for example, can occur because packets are dropped all
at once due to tail drop. Global synchronization manifests when
multiple TCP hosts reduce their transmission rates in response to
packet dropping, then increase their transmission rates once again
when the congestion is reduced. This leads to poor adaptive streaming
performance when the CDNi interface links are congested especially
during peak hours.
Enabling Random Early Discard (RED) [RFC2309] on the CDNi interface
links for HAS traffic, results in better adaptive streaming
performance when the CDNi interface links are congested especially
during peak hours. The following explains the WRED behavior in
detail. RED aims to control the average queue size by indicating to
the end hosts when they should temporarily slow down transmission of
packets. WRED takes advantage of the congestion control mechanism of
TCP. By randomly dropping packets prior to periods of high
congestion, RED tells the packet source to decrease its transmission
rate. The packet source is using TCP, or in effect the HAS end user,
will decrease its transmission rate until all the packets reach
their destination, indicating that the congestion is cleared. TCP
not only pauses, but it also restarts quickly and adapts its
transmission rate to the rate that the network can support. RED
Krishnan, et al. Expires January 30, 2013 [Page 4]
Internet-Draft TM Models for HAS aware CDN Interconnection July 2012
distributes losses in time and maintains normally low queue depth
while absorbing spikes.
Weighted Random Early Discard (WRED) is an improved version of RED
which provides separate queue thresholds for different traffic
classes, enabling the provision of different qualities of service for
different traffic classes [RFC2474]. Using WRED, low priority HAS
traffic may be dropped more frequently than high priority HAS traffic
during periods of congestion. The example below demonstrates how WRED
can be configured to improve HAS performance and offer differentiated
services for different types of HAS traffic.
4.1. WRED Configuration Example
As depicted in Figure 1, both CDN-A and CDN-B establish
interconnections with CDN-C that acts as a dCDN. Thus, CDN-C will
cache the content for CDN-A and CDN-B. When both CDN provider A and
CDN provider B have agreements with the same CSP for content
delivery, CDN-C may be required by CDN-A and CDN-B separately to
retrieve and cache the same content from the CSP. WRED is enabled on
the CDNi interface between CDN-A <-> CDN-C and CDN-B <-> CDN-C. The
router configuration is depicted below.
Krishnan, et al. Expires January 30, 2013 [Page 5]
Internet-Draft TM Models for HAS aware CDN Interconnection July 2012
+-------+
| CSP |
+-------+
/ \
,--,--,--./ \,--,--,--.
,-' `-. ,-' `-.
( CDN Provider A ) ( CDN Provider B )
`-. (CDN-A) ,-' `-. (CDN-B) ,-'
`--'--'--' `--'--'--'
\\ //
WRED <---------- \\,--,--,--.// --------> WRED
,-' `-.
( CDN Provider C )
`-. (CDN-C) ,-'
`--'--'--'
|
+------------+
| User Agent |
+------------+
=== CDN Interconnect
Figure 1 Interconnected CDNs with WRED enabled across CDNi
Krishnan, et al. Expires January 30, 2013 [Page 6]
Internet-Draft TM Models for HAS aware CDN Interconnection July 2012
4.1.1. Router buffering and queueing recommendations
Amount of buffers needed = Round Trip Time (RTT) x link capacity of
bottleneck link; in this case, the bottleneck link is typically the
CDNi link
The is a separate queue per <output port, priority>; typically there
are 8 priorities
4.1.2. IP DSCP and Queue size mapping for IPv4 traffic recommendations
Map HAS traffic to a IP DSCP Assured Forwarding (AF) class, e.g.
class 3 (IP precedence 3)
High priority HAS traffic
Marked with low drop precedence e.g. AF31
Queue threshold to trigger random packet drop - high value
Drop probability - low value
Medium priority HAS traffic
Marked with medium drop precedence e.g. AF32
Queue threshold to trigger random packet drop - medium value
Drop probability - medium value
Low priority HAS traffic
Marked with high drop precedence e.g. AF33
Queue threshold to trigger random packet drop - low value
Drop probability - high value
Krishnan, et al. Expires January 30, 2013 [Page 7]
Internet-Draft TM Models for HAS aware CDN Interconnection July 2012
5. References
5.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC
2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors),
"Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, Internet Mail Consortium
and Demon Internet Ltd., November 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
5.2. Informative References
[I-D.ietf-cdni-framework]L. Peterson, "Framework for CDN
Interconnection", April 2012.
[I-D.ietf-cdni-problem-statement]B. Niven-Jenkins, "Content
Distribution Network Interconnection (CDNi) Problem
Statement", May 2012.
[I-D.ietf-cdni-requirements]K. Leung, "Content Distribution Network
Interconnection (CDNi) Requirements", December 2011.
[RFC2309] B. Braden, "Recommendations on Queue Management and
Congestion Avoidance", April 1998
[RFC 2474] K. Nichols, "Definition of the Differentiated Services
Field (DS Field) in the IPv4 and IPv6 Headers", December 1998
Authors' Addresses
Ram Krishnan
Brocade Communications
San Jose, 95134, USA
Krishnan, et al. Expires January 30, 2013 [Page 8]
Internet-Draft TM Models for HAS aware CDN Interconnection July 2012
Phone: +001-408-406-7890
Email: ramk@brocade.com
Bhumip Khasnabish
ZTE Corporation
New Jersey, 07960, USA
Phone: +001-781-752-8003
Email: bhumip.khasnabish@zteusa.com
Krishnan, et al. Expires January 30, 2013 [Page 9]
