idnits 2.17.1 draft-tschofenig-conex-ps-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2010) is 5163 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC2975' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'RFC3576' is defined on line 375, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-irtf-p2prg-mythbustering-01 == Outdated reference: A later version (-09) exists of draft-livingood-woundy-congestion-mgmt-03 -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4006 (Obsoleted by RFC 8506) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CONEX H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational A. Cooper 5 Expires: September 9, 2010 Center for Democracy & 6 Technology 7 March 8, 2010 9 Congestion Exposure Problem Statement 10 draft-tschofenig-conex-ps-02.txt 12 Abstract 14 The increasingly ubiquitous availability of broadband, together with 15 flat-rate pricing, have made for increasing congestion problems on 16 the network, which are often caused by a small number of users 17 consuming a large amount of bandwidth. In some cases, building out 18 more capacity to handle this new congestion may be infeasible or 19 unwarranted. As a result, network operators have sought other ways 20 to manage congestion both from their own users and from other 21 networks. These different types of solutions have different 22 strengths and weaknesses, but all of them are limited in a number of 23 key ways. 25 This document discusses the problems created for operators by high- 26 consuming users and describes the strengths and weaknesses of a 27 number of techniques operators are currently using to cope with high 28 bandwidth usage. The discussion of these solutions ultimately points 29 to a need for a new kind of congestion accounting. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 This Internet-Draft will expire on September 9, 2010. 54 Copyright Notice 56 Copyright (c) 2010 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Existing Approaches to Congestion Management . . . . . . . . . 5 73 2.1. Volume-Based Approaches . . . . . . . . . . . . . . . . . 5 74 2.2. Rate-Based Approaches . . . . . . . . . . . . . . . . . . 5 75 2.3. Congestion-Based Approaches . . . . . . . . . . . . . . . 5 76 2.4. Applications-Based Approaches . . . . . . . . . . . . . . 6 77 3. General Limitations of All Approaches . . . . . . . . . . . . 7 78 4. New Activities . . . . . . . . . . . . . . . . . . . . . . . . 8 79 5. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 Appendix A. Example Policy Statement . . . . . . . . . . . . . . 15 87 A.1. Fair Usage Policy . . . . . . . . . . . . . . . . . . . . 15 88 A.1.1. What is the Fair Usage Policy? . . . . . . . . . . . . 15 89 A.1.2. How do I know I'm a very heavy user? . . . . . . . . . 15 90 A.1.3. I have Contract Option 3, does the Fair Usage 91 Policy apply to me? . . . . . . . . . . . . . . . . . 15 92 A.1.4. Peer to Peer (P2P) . . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 95 1. Introduction 97 With the growth of "always on" broadband connections, network 98 operators are increasingly facing congestion problems caused by a 99 small number of network users occupying a large proportion of network 100 capacity [broadband-traffic-report][traffic2]. This trend does not 101 necessarily present a problem on its face, as increased traffic 102 volumes do not automatically lead to congestion. However, in some 103 cases where operators were not expecting these changes in growth 104 rates and traffic consumption, their pricing models and congestion 105 management architectures have proved inadequate. This is true of 106 both congestion caused by an operator's own subscribers and 107 congestion caused by an interconnecting network. 109 In some cases, building out more capacity to handle this new 110 congestion may be infeasible or unwarranted. The cost of building 111 new capacity may be prohibitive, especially for network operators 112 that charge flat-rate feeds to subscribers and are thus unable to 113 charge heavier users more on the basis of their larger contribution 114 to the congestion problem. For an operator facing congestion caused 115 by other operators' networks, building out its own capacity is 116 unlikely to solve the congestion problem. Operators are thus facing 117 increased pressure to find effective solutions to dealing with high- 118 consuming users, other than building out new capacity. 120 There are many factors to consider for each kind of solution, 121 including how the solution performs, its cost, what its public 122 relations impact might be, and what legal framework exists to support 123 its use. The performance considerations must take into account the 124 balance between device performance and forwarding performance (since 125 many of the solution mechanisms slow down forwarding performance), 126 and this determination is intimiately related to measuring a 127 solution's overall cost. 129 The responses that operators have sought to manage congestion both 130 from their own users and from other networks are generally based on 131 one of four factors that the operator can observe for each subscriber 132 or hand-off point on the network: volume of bandwidth used, rates of 133 data transfer, congestion volume, and applications used. These 134 different types of solutions have different strengths and weaknesses, 135 but all of them are limited in a number of key ways. Section 2 136 discusses the specific strengths and weaknesses of each approach. 137 Section 3, discusses the limitations that are common to all of the 138 approaches. 140 2. Existing Approaches to Congestion Management 142 2.1. Volume-Based Approaches 144 The volume of traffic sent or received by a particular user or 145 network is easy to measure. Operators have a number of different 146 standardized protocols available to them to conduct volume 147 accounting. Many information elements can be sent from an accounting 148 client to an accounting server using standardized protocols, such as 149 RADIUS (see [RFC2866] and [RFC2865]) and Diameter [RFC3588], to 150 effectuate volume-based accounting. The existence of standardized 151 protocols has allowed resource consumption measurement in roaming 152 cases due to the interconnected AAA systems. These protocols are now 153 used in almost every enterprise and operator network. The initial 154 accounting mechanisms envisioned a rather non-real time nature in 155 reporting resource consumption but with mechanisms like like Diameter 156 Credit Control [RFC4006] allowed real-time credit control checks, 157 allowing operators to make fine-grained congestion decisions based on 158 volume. 160 If the collected accounting information leads to billable events then 161 this typically leads to a quite effective countermeasure against 162 heavy usage. For example, data usage while roaming is often charged 163 per volume (or per time) and heavy usage leads to huge costs. So, 164 user's typically avoid heavy usage unless they are not aware of the 165 fact that they are roaming, which may happen. 167 In any case, the drawback of all of these approaches is that they 168 tend to be less user friendly nor do they reflect congestion in any 169 way. 171 2.2. Rate-Based Approaches 173 Volume-based protocols are blind to protocols like LEDBAT [ledbat] 174 that are specifically designed to be more sensitive to congestion 175 than the underlying transport. One way that operators have used 176 volume accounting is by including thresholds for baseline usage 177 volume in end user contracts and reducing priority (or charging fees) 178 when a user's consumption goes beyond the threshold. Under such a 179 scheme, users would not be incentivized to use applications that 180 support protocols like LEDBAT, because the volume accounting would 181 not take the congestion benefits of using a LEDBAT-style protocol 182 into consideration. 184 2.3. Congestion-Based Approaches 186 Initial attempts to capture congestion situations have simply focused 187 on the peak hours and aimed at rate limiting heavy users during that 188 time. For example, users who have consumed a certain amount of 189 bandwidth during the last 24 hours got elected as those who get their 190 traffic shaped, in case the total amount of traffic reaches a 191 congestion situation in certain nodes within the operators network. 193 More sophisticated schemes were developed to measure the congestion 194 situation at different entities in the network and to take the 195 overall consumption of the user's traffic into account when picking 196 users for packet remarking that could lead, under congestion 197 situation, to packet dropping. The Comcast FairShare solution 198 [I-D.livingood-woundy-congestion-mgmt] belongs to the more 199 sophisticated schemes. 201 2.4. Applications-Based Approaches 203 The use of deep packet inspection (DPI) allows operators to observe 204 and analyze traffic at the application layer. This capability can be 205 used to determine the applications and/or application-layer protocols 206 that subscribers are using and respond on a per-application or per- 207 protocol basis. An example of an ISP's fair usage policy describing 208 how it manages specific protocols is included in Appendix A. 210 If an operator experiences much congestion based on the use of easily 211 identifiable applications protocols, or if the DPI capability can 212 also be used for other purposes, operators may find this approach 213 attractive. However, the applications-based approach has some 214 drawbacks. The process of inspecting traffic, particularly in real 215 time, can be highly performance-intensive. DPI equipment may also 216 require continous software updates to ensure that the detection 217 engine recognizes the latest protocol variants, and its use can 218 result in a cat-and-mouse game with applications developers 219 constantly seeking ways to work around the packet inspection engine. 220 Public policy concerns -- privacy, operator liability, user backlash, 221 and others -- are another drawback. 223 3. General Limitations of All Approaches 225 All three of the approaches discussed above suffer from some general 226 limitations. First, they introduce performance uncertainty. Flat- 227 rate pricing plans are popular because operators know that users 228 appreciate the certainty of having their monthly bill amount remain 229 the same for each billing period, allowing users to plan their costs 230 accordingly. But while flat-rate pricing avoids billing uncertainty, 231 it creates performance uncertainty: users cannot be sure that the 232 performance of their connections is not being altered or degrated 233 based on how the network operator manages congestion. 235 Second, none of the approaches is able to make use of what may be the 236 most important factor in managing congestion: the amount that an 237 endpoint contributes to congestion on the network. This information 238 simply is not available to network nodes, and neither volume nor rate 239 nor application usage is an adequate proxy for congestion volume, 240 because none of these metrics measures a user or network's actual 241 contribution to congestion on the network. [This point needs a 242 little more discussion.] 244 Finally, none of these solutions accounts for inter-network 245 congestion. The currently available mechanisms for identifying and 246 mitigating congestion largely run wholly within an operator's network 247 and without a lot of information exchange about congestion 248 information to or from end hosts or other network operators. 249 Exposing this information may allow end devices to make more informed 250 decisions (although policy enforcement would still be required by the 251 operator). [This point needs to be filled in more.] 253 4. New Activities 255 Following the IETF Workshop on Peer-to-Peer (P2P) Infrastructure in 256 2008 (see [RFC5594]), two working groups and one research group were 257 created that relate to the congestion issues created by peer-to-peer 258 application usage: : 260 LEDBAT (Low Extra Delay Background Transport) [ledbat] is designed 261 to keep the latency across a congested bottleneck low even as it 262 is saturated. This allows applications that send large amounts of 263 data, particularly upstream on home connections (such as peer-to- 264 peer applications) to operate without destroying the user 265 experience in interactive applications. 267 LEDBAT holds substantial promise should P2P clients adopt it 268 widely. This solution has been focused on P2P applications, and 269 its applicability to other applications, such as video using 270 H.264, is unclear. 272 ALTO (Application-Layer Traffic Optimization) [alto] aims to 273 design and specify mechanisms that will provide applications, 274 typically P2P applications, with information to perform better- 275 than-random initial peer selection to increase their performance 276 and at the same time to avoid excessive cross-domain traffic that 277 tends to be more expensive for the operator. ALTO services may 278 take different approaches at balancing factors such as maximum 279 bandwidth, minimum cross-domain traffic, or lowest cost to the 280 user, but in all cases the goal is to expose information that can 281 ameliorate the interactions between peer-to-peer usage and other 282 usages of shared networks. 284 Peer to Peer Research Group [p2prg] aims to provide a discussion 285 forum for resarchers related to all sorts of challenges presented 286 by P2P systems in general, such as P2P streaming, interconnecting 287 distinct P2P application overlays, security and privacy. Current 288 work on exposing myths about peer-to-peer filesharing 289 [I-D.irtf-p2prg-mythbustering] provides a number of references to 290 support some of the claimed benefits of ALTO solutions mechanisms, 291 such as the expected decrease in cross- domain traffic. 293 5. Next Steps 295 Congestion is a reality. Operators that would like to counteract the 296 impact of congestion on their networks have a fair number of tools at 297 their disposal. These tools may allow operators to identify heavy 298 users, collect performance and usage indications, and choose from a 299 variety of mitigating steps depending on the operator's preferred 300 business practices. Subscriber-specific information, including 301 policies, resource consumption information, and details about the 302 current network attachment point, may be available in accounting 303 servers. Information about the network topology and the state of 304 particular topology elements may be available in the network 305 management infrastructure. Solution approaches similar to 306 [I-D.livingood-woundy-congestion-mgmt] have demonstrated one way of 307 taking congestion information into consideration. 309 The collection of congestion information poses the challenge of 310 deciding where in the network to put the metering agents to ensure 311 that enough information is collected at the right point in time. 312 Distributed collection and the correlation of the information across 313 different nodes is a complex task. An approach that collects this 314 congestion information along the path of the data packet (via inband 315 signaling) would simplify this task. Regardless of the technical 316 solution utilized for collecting information, certain users will 317 undoubtedly observe the effects of decisions that operators make 318 about how to handle congestion. Allowing users to understand these 319 decisions will be crucial and having a channel to send feedback to 320 the end device and/or subscriber would be a helpful step towards 321 increased transparency. 323 6. Security Considerations 325 This document highlights approaches for dealing with high-consuming 326 network users and all of them raise security and privacy concerns. 327 It does not introduce new mechanisms. The security considerations 328 for the existing mechanisms mentioned apply. 330 7. IANA Considerations 332 This document does not require actions by IANA. 334 8. Acknowledgments 336 The authors would like to thank Alan DeKok, Jens-Peter Haack, 337 Alexander Bachmutsky, Jonne Soininen, Joachim Charzinski, Hannu 338 Flinck, Joachim Kross, Jouni Korhonen, Mayutan Arumaithurai, Richard 339 Woundy, Daniel Correa Lobato, Luca Caviglione, Tommy Lindgren, Lars 340 Eggert, and Jason Livingood for their time to discuss the topic. 341 Additionally, we would like to thank Marcin Matuszewski for his help 342 with the P2P infrastructure workshop paper (since it was used as a 343 starting point for the work on this memo). 345 9. References 347 9.1. Normative References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 9.2. Informative References 354 [I-D.irtf-p2prg-mythbustering] 355 Marocco, E., Fusco, A., Rimac, I., and V. Gurbani, 356 "Improving Peer Selection in Peer-to-peer Applications: 357 Myths vs. Reality", draft-irtf-p2prg-mythbustering-01 358 (work in progress), March 2010. 360 [I-D.livingood-woundy-congestion-mgmt] 361 Bastian, C., Klieber, T., Livingood, J., Mills, J., and R. 362 Woundy, "Comcast's Protocol-Agnostic Congestion Management 363 System", draft-livingood-woundy-congestion-mgmt-03 (work 364 in progress), February 2010. 366 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 367 "Remote Authentication Dial In User Service (RADIUS)", 368 RFC 2865, June 2000. 370 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 372 [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to 373 Accounting Management", RFC 2975, October 2000. 375 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 376 Aboba, "Dynamic Authorization Extensions to Remote 377 Authentication Dial In User Service (RADIUS)", RFC 3576, 378 July 2003. 380 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 381 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 383 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 384 Loughney, "Diameter Credit-Control Application", RFC 4006, 385 August 2005. 387 [RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop 388 on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", 389 RFC 5594, July 2009. 391 [alto] "", 392 . 394 [broadband-traffic-report] 395 Cho, K., "Broadband Traffic Report", Internet 396 Infrastructure Review 4, 2009. 398 [ledbat] "", 399 . 401 [p2prg] "", . 403 [traffic] Cho, K., Fukuda, K., Kato, H., and A. Kato, "The impact 404 and implications of the growth in residential user-to-user 405 traffic", SIGCOMM Comput. Commun. Rev. 36, 2006. 407 [traffic2] 408 Cho, K., Fukuda, K., Esaki, H., and A. Kato, "Observing 409 slow crustal movement in residential user traffic, in 410 International Conference On Emerging Networking 411 Experiments And Technologies, Proceedings of the 2008 ACM 412 CoNEXT Conference, Madrid, Spain, Article No. 12", , 413 2008. 415 Appendix A. Example Policy Statement 417 A.1. Fair Usage Policy 419 A.1.1. What is the Fair Usage Policy? 421 The Fair Usage Policy is designed to ensure that the service received 422 by the vast majority of our customers is not negatively impacted 423 because of extremely heavy usage by a very small minority of 424 customers. This is why ISP X continuously monitors network 425 performance and may restrict the speed available to very heavy users 426 during peak time. This applies to customers on all Options. Note if 427 you are a heavy user we will only restrict your speed, service will 428 not be stopped so ability to upload and download remains. No 429 restrictions will be imposed outside of the peak times. Only a very 430 small minority of customers will ever be affected by this (less than 431 1 %). 433 A.1.2. How do I know I'm a very heavy user? 435 There is no hard and fast usage limit that determines if you are a 436 heavy user as the parameters that determine heavy use vary with the 437 demands placed on the network at that given time. If you have a 438 query about fair usage related restrictions on your line please call 439 us. 441 A.1.3. I have Contract Option 3, does the Fair Usage Policy apply to 442 me? 444 Yes, the Fair Usage Policy applies to all customers on all Options, 445 including Option 3. Option 3 allows unlimited downloads and uploads 446 inclusive of the monthly rental price, so you will not be charged for 447 over-use, however this does not preclude ISP X from restricting your 448 speed at peak times if you are a heavy user. If you are an Option 3 449 heavy user this does not prevent you from continuing to use your 450 service, nor does it cost you any more but it ensures that you do not 451 negatively impact the majority of our customers who share the 452 available bandwidth with you. 454 A.1.4. Peer to Peer (P2P) 456 A.1.4.1. I'm noticing slower P2P speeds at peak times even though I'm 457 not a very heavy user, why is this? 459 P2P is the sharing and delivery of files amongst groups of people who 460 are logged on to a file sharing network. P2P consumes a significant 461 and highly disproportionate amount of bandwidth when in use even by 462 small numbers of users. 464 This is why we have a peak time policy where we limit P2P speeds to 465 manage the amount of bandwidth that is used by this application in 466 particular. 468 Without these limits all our customers using their broadband service 469 at peak times would suffer, regardless of whether they are using P2P 470 or not. It's important to remember that P2P isn't a time-critical 471 application so if you do need to download large files we advise you 472 to do this at off-peak times when no restrictions are placed, not 473 only will you be able to download faster but your usage will not 474 negatively impact other users. 476 A.1.4.2. Does this mean I can't use Peer-to-Peer (P2P) applications? 478 No, we are not stopping you from using any P2P service, P2P will just 479 be slowed down at peak times. Again, P2P is not generally a time- 480 sensitive application. 482 Authors' Addresses 484 Hannes Tschofenig 485 Nokia Siemens Networks 486 Linnoitustie 6 487 Espoo FIN-02600 488 Finland 490 Phone: +358 (50) 4871445 491 Email: Hannes.Tschofenig@gmx.net 492 URI: http://www.tschofenig.priv.at 494 Alissa Cooper 495 Center for Democracy & Technology 496 1634 I Street NW, Suite 1100 497 Washington, DC 498 USA 500 Email: acooper@cdt.org