idnits 2.17.1 draft-krishnan-cdni-tm-has-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 158 has weird spacing: '...default cong...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 2012) is 4287 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'I-D.brandenburg-cdni-has-03' on line 110 looks like a reference -- Missing reference section? 'RFC2119' on line 300 looks like a reference -- Missing reference section? 'I-D.ietf-cdni-problem-statement-06' on line 124 looks like a reference -- Missing reference section? 'I-D.ietf-cdni-requirements-03' on line 126 looks like a reference -- Missing reference section? 'I-D.ietf-cdni-framework-00' on line 128 looks like a reference -- Missing reference section? 'I-D.ietf-cdni-use-cases-08' on line 130 looks like a reference -- Missing reference section? 'RFC2309' on line 319 looks like a reference -- Missing reference section? 'RFC2474' on line 191 looks like a reference -- Missing reference section? '1' on line 291 looks like a reference -- Missing reference section? '2' on line 295 looks like a reference -- Missing reference section? 'RFC2234' on line 303 looks like a reference -- Missing reference section? 'RFC 2474' on line 322 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CDNI R. Krishnan 2 Internet Draft Brocade Communications 3 Intended status: Informational B. Khasnabish 4 Expires: January 2013 ZTE Corporation 5 July 30, 2012 7 Traffic management models for http adaptive-streaming-aware CDN 8 Interconnection 9 draft-krishnan-cdni-tm-has-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may not be modified, 18 and derivative works of it may not be created, and it may not be 19 published except as an Internet-Draft. 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. This document may not be modified, 23 and derivative works of it may not be created, except to publish it 24 as an RFC and to translate it into languages other than English. 26 This document may contain material from IETF Documents or IETF 27 Contributions published or made publicly available before November 28 10, 2008. The person(s) controlling the copyright in some of this 29 material may not have granted the IETF Trust the right to allow 30 modifications of such material outside the IETF Standards Process. 31 Without obtaining an adequate license from the person(s) controlling 32 the copyright in such materials, this document may not be modified 33 outside the IETF Standards Process, and derivative works of it may 34 not be created outside the IETF Standards Process, except to format 35 it for publication as an RFC or to translate it into languages other 36 than English. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html 53 This Internet-Draft will expire on Fail 30, 0000. 55 Copyright Notice 57 Copyright (c) 0000 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (http://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with respect 75 to this document. 77 Abstract 79 This document presents thoughts on the traffic management aspects of 80 supporting HTTP Adaptive Streaming technologies in CDN 81 Interconnection scenarios. Our intent is to recommend traffic 82 management techniques which can offer the best adaptive streaming 83 performance over CDN interconnections. 85 Table of Contents 87 1. Introduction...................................................3 88 2. Conventions used in this document..............................3 89 3. CDNi interface bandwidth challenges............................3 90 4. CDNi interface traffic management..............................4 91 4.1. WRED Configuration Example................................5 92 4.1.1. Router buffering and queueing recommendations........7 93 4.1.2. IP DSCP and Queue size mapping for IPv4 traffic 94 recommendations.............................................7 95 5. References.....................................................8 96 5.1. Normative References......................................8 97 5.2. Informative References....................................8 99 1. Introduction 101 HTTP Adaptive Streaming (HAS) is an umbrella term for various HTTP- 102 based streaming technologies that allow a client to adaptively switch 103 between multiple bitrates depending on current network conditions. A 104 defining aspect of HAS is that, since it is based on HTTP, it is a 105 pull-based mechanism, with a client actively requesting content 106 segments, instead of the content being pushed to the client by a 107 server. The underlying protocol used by HTTP is TCP/IP. This document 108 presents the challenges in CDNi interface bandwidth provisioning, 109 given the heavy asymmetric usage of the network between peak and 110 quiet hours. The document [I-D.brandenburg-cdni-has-03] recommends 111 various models for adaptive streaming aware CDN interconnection. This 112 document complements the above document by recommending traffic 113 management techniques which can offer the best adaptive streaming 114 performance over CDN interconnections during hours of congestion. 116 2. Conventions used in this document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 This document reuses the terminology defined in: 124 [I-D.ietf-cdni-problem-statement-06], 126 [I-D.ietf-cdni-requirements-03], 128 [I-D.ietf-cdni-framework-00], and 130 [I-D.ietf-cdni-use-cases-08]. 132 3. CDNi interface bandwidth challenges 134 Typically, the interface between CDNs is a long-haul backbone network 135 where bandwidth is premium. The bandwidth needs of HAS is directly 136 proportional to the number of active end users who are streaming 137 video. The bandwidth requirements of HAS are quite asymmetric, with 138 the bandwidth usage during peak family hours is substantially higher 139 as compared to the normal hours. Caching in the CDN-I alleviates this 140 to a certain degree, but we could have network congestion in the 141 following scenarios 1) During peak hours, in a pull model caching, 142 the first copy of many HAS streams would be delivered. 2) Long-tail 143 personalized content, which is not amenable to caching, is desired by 144 the end user. A naive solution would be to dimension the CDNi 145 bandwidth for the peak hour usage and projected user growth which can 146 lead to an expensive backbone network infrastructure. By using 147 traffic management techniques described below, this issue network 148 congestion issue can be alleviated by to a great degree and the 149 backbone network need not be dimensioned for peak usage. 151 4. CDNi interface traffic management 153 The CDNi interface links, which are typically long haul, have much 154 lower bandwidth as compared to the links in the CDN. As discussed in 155 the previous section, there is potential for congestion in the CDNi 156 interface links especially during peak hours. The underlying protocol 157 used by HAS is TCP/IP. In the standard router configuration, the 158 default congestion avoidance behavior for TCP/IP traffic is tail 159 drop. Tail drop causes global synchronization of TCP/IP hosts or in 160 effect the end users of HAS. Global synchronization occurs as waves 161 of congestion crest only to be followed by troughs during which the 162 CDNi interface link(s) are not fully utilized. Global synchronization 163 of TCP hosts, for example, can occur because packets are dropped all 164 at once due to tail drop. Global synchronization manifests when 165 multiple TCP hosts reduce their transmission rates in response to 166 packet dropping, then increase their transmission rates once again 167 when the congestion is reduced. This leads to poor adaptive streaming 168 performance when the CDNi interface links are congested especially 169 during peak hours. 171 Enabling Random Early Discard (RED) [RFC2309] on the CDNi interface 172 links for HAS traffic, results in better adaptive streaming 173 performance when the CDNi interface links are congested especially 174 during peak hours. The following explains the WRED behavior in 175 detail. RED aims to control the average queue size by indicating to 176 the end hosts when they should temporarily slow down transmission of 177 packets. WRED takes advantage of the congestion control mechanism of 178 TCP. By randomly dropping packets prior to periods of high 179 congestion, RED tells the packet source to decrease its transmission 180 rate. The packet source is using TCP, or in effect the HAS end user, 181 will decrease its transmission rate until all the packets reach 182 their destination, indicating that the congestion is cleared. TCP 183 not only pauses, but it also restarts quickly and adapts its 184 transmission rate to the rate that the network can support. RED 185 distributes losses in time and maintains normally low queue depth 186 while absorbing spikes. 188 Weighted Random Early Discard (WRED) is an improved version of RED 189 which provides separate queue thresholds for different traffic 190 classes, enabling the provision of different qualities of service for 191 different traffic classes [RFC2474]. Using WRED, low priority HAS 192 traffic may be dropped more frequently than high priority HAS traffic 193 during periods of congestion. The example below demonstrates how WRED 194 can be configured to improve HAS performance and offer differentiated 195 services for different types of HAS traffic. 197 4.1. WRED Configuration Example 199 As depicted in Figure 1, both CDN-A and CDN-B establish 200 interconnections with CDN-C that acts as a dCDN. Thus, CDN-C will 201 cache the content for CDN-A and CDN-B. When both CDN provider A and 202 CDN provider B have agreements with the same CSP for content 203 delivery, CDN-C may be required by CDN-A and CDN-B separately to 204 retrieve and cache the same content from the CSP. WRED is enabled on 205 the CDNi interface between CDN-A <-> CDN-C and CDN-B <-> CDN-C. The 206 router configuration is depicted below. 208 +-------+ 210 | CSP | 212 +-------+ 214 / \ 216 ,--,--,--./ \,--,--,--. 218 ,-' `-. ,-' `-. 220 ( CDN Provider A ) ( CDN Provider B ) 222 `-. (CDN-A) ,-' `-. (CDN-B) ,-' 224 `--'--'--' `--'--'--' 226 \\ // 228 WRED <---------- \\,--,--,--.// --------> WRED 230 ,-' `-. 232 ( CDN Provider C ) 234 `-. (CDN-C) ,-' 236 `--'--'--' 238 | 240 +------------+ 242 | User Agent | 244 +------------+ 246 === CDN Interconnect 248 Figure 1 Interconnected CDNs with WRED enabled across CDNi 250 4.1.1. Router buffering and queueing recommendations 252 Amount of buffers needed = Round Trip Time (RTT) x link capacity of 253 bottleneck link; in this case, the bottleneck link is typically the 254 CDNi link 256 The is a separate queue per ; typically there 257 are 8 priorities 259 4.1.2. IP DSCP and Queue size mapping for IPv4 traffic recommendations 261 Map HAS traffic to a IP DSCP Assured Forwarding (AF) class, e.g. 262 class 3 (IP precedence 3) 264 High priority HAS traffic 266 Marked with low drop precedence e.g. AF31 268 Queue threshold to trigger random packet drop - high value 270 Drop probability - low value 272 Medium priority HAS traffic 274 Marked with medium drop precedence e.g. AF32 276 Queue threshold to trigger random packet drop - medium value 278 Drop probability - medium value 280 Low priority HAS traffic 282 Marked with high drop precedence e.g. AF33 284 Queue threshold to trigger random packet drop - low value 286 Drop probability - high value 287 5. References 289 5.1. Normative References 291 [1] Bradner, S., "Key words for use in RFCs to 292 Indicate Requirement Levels", BCP 14, RFC 293 2119, March 1997. 295 [2] Crocker, D. and Overell, P.(Editors), 296 "Augmented BNF for Syntax Specifications: 297 ABNF", RFC 2234, Internet Mail Consortium 298 and Demon Internet Ltd., November 1997. 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, March 1997. 303 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 304 Syntax Specifications: ABNF", RFC 2234, Internet Mail 305 Consortium and Demon Internet Ltd., November 1997. 307 5.2. Informative References 309 [I-D.ietf-cdni-framework]L. Peterson, "Framework for CDN 310 Interconnection", April 2012. 312 [I-D.ietf-cdni-problem-statement]B. Niven-Jenkins, "Content 313 Distribution Network Interconnection (CDNi) Problem 314 Statement", May 2012. 316 [I-D.ietf-cdni-requirements]K. Leung, "Content Distribution Network 317 Interconnection (CDNi) Requirements", December 2011. 319 [RFC2309] B. Braden, "Recommendations on Queue Management and 320 Congestion Avoidance", April 1998 322 [RFC 2474] K. Nichols, "Definition of the Differentiated Services 323 Field (DS Field) in the IPv4 and IPv6 Headers", December 1998 325 Authors' Addresses 327 Ram Krishnan 329 Brocade Communications 331 San Jose, 95134, USA 332 Phone: +001-408-406-7890 334 Email: ramk@brocade.com 336 Bhumip Khasnabish 338 ZTE Corporation 340 New Jersey, 07960, USA 342 Phone: +001-781-752-8003 344 Email: bhumip.khasnabish@zteusa.com