idnits 2.17.00 (12 Aug 2021) /tmp/idnits64182/draft-tschofenig-conex-ps-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (October 26, 2009) is 4590 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'RFC3576' is defined on line 396, but no explicit reference was found in the text == Outdated reference: draft-irtf-p2prg-mythbustering has been published as RFC 6821 == Outdated reference: draft-livingood-woundy-congestion-mgmt has been published as RFC 6057 -- 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 (~~), 5 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: April 29, 2010 Center for Democracy & 6 Technology 7 October 26, 2009 9 Congestion Exposure Problem Statement 10 draft-tschofenig-conex-ps-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 29, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 The increasingly ubiquitous availability of broadband, together with 49 flat-rate pricing, have made the use of new kinds of peer-to-peer 50 applications increasingly common. From the perspective of the 51 Internet's evolution and its contributions to end user value, this is 52 very exciting. However, the uptick in peer-to-peer application usage 53 has also contributed to the rise of "high-consuming users" who take 54 their flat-rate contracts to the limit by continuously file-sharing 55 to the maximum extent possible. Network operators have responded to 56 this phenomenon in a number of different fashions. 58 This document discusses the problems created for operators by high- 59 consuming users and illustrates a number of techniques operators are 60 currently using to cope with high bandwidth usage. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. State-of-the-Art Building Blocks . . . . . . . . . . . . . . . 5 66 2.1. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.2. Deep Packet Inspection . . . . . . . . . . . . . . . . . . 5 68 3. Network Operator Responses to Congestion . . . . . . . . . . . 7 69 4. New Activities . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 77 Appendix A. Example Policy Statement . . . . . . . . . . . . . . 16 78 A.1. Fair Usage Policy . . . . . . . . . . . . . . . . . . . . 16 79 A.1.1. What is the Fair Usage Policy? . . . . . . . . . . . . 16 80 A.1.2. How do I know I'm a very heavy user? . . . . . . . . . 16 81 A.1.3. I have Contract Option 3, does the Fair Usage 82 Policy apply to me? . . . . . . . . . . . . . . . . . 16 83 A.1.4. Peer to Peer (P2P) . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 In recent years, network operators around the world have begun to 89 feel the affects of "high-consuming users" -- those who use the 90 maximum amount of bandwidth possible, usually for the purpose of 91 peer-to-peer file sharing. In 2006 K. Cho et al. [traffic] reported 92 that for residential Japanese broadband connections, "a small number 93 of users dictate the overall behavior; 4% of high-consuming users 94 account for 75% of the inbound volume, and the fiber users account 95 for 86% of the inbound volume." A more recent paper published 96 December 2008, see [traffic2], confirms that the distribution has not 97 changed much. User-to-user traffic comprised 63% of overall 98 residential traffic volume. The authors noted not only a changing 99 traffic distribution, but also a substantial increase in overall 100 traffic growth (37% per year). Operators in other countries have 101 experienced similar shifts. 103 This trend does not necessarily present a problem on its face, as 104 increased traffic volumes do not automatically lead to congestion. 105 However, in some cases where operators were not expecting these 106 changes in growth rates and traffic consumption, their pricing models 107 and congestion management architectures have proved inadequate. In 108 some countries, fierce competition among Internet access providers 109 has yielded low profit margins. This has increased the pressure on 110 operators to find effective ways to deal with high- consuming users 111 who cost them more money than the bulk of their subscribers. 112 Furthermore, some broadband networks (such as cable networks) may not 113 have the ideal characteristics (routing topology, for example) to 114 support high volumes of user-to-user traffic. 116 Congestion and cost are closely related. As stated in RFC 5594 117 [RFC5594], "... congestion can be viewed merely as a manifestation of 118 cost. An ISP that invests in capacity could be considered to be 119 paying to relieve congestion. Or, if subscribers are charged for 120 congesting the network, then cost and congestion could be viewed as 121 one and the same. The distinction between them may thus be 122 artificial.". The upshot for network operators is: those who produce 123 a lot of traffic cost a lot. 125 Operators are now facing a range of options for addressing this 126 problem. There are many factors to consider for each kind of 127 solution, including how the solution performs, its cost, what the 128 public relations impact of using a particular solution might be, and 129 what legal framework exists to support the use of a particular 130 solution. The performance considerations must take into account the 131 balance between device performance and forwarding performance (since 132 many of the solution mechanisms slow down forwarding performance), 133 and this determination is intimiately related to measuring a 134 solution's overall cost. 136 In some cases, the popularity of flat-rate pricing plans exacerbate 137 the congestion problem because an individual's bandwidth usage is not 138 tied to his or her monthly bill, creating an incentive to use as much 139 bandwidth as possible and leaving operators to cover the costs of all 140 their users with essentially equal payments from each. Operators 141 know that users appreciate the certainty of having the bill amount 142 remain the same for each billing period, allowing users to plan their 143 costs accordingly. But while flat-rate pricing avoids billing 144 uncertainty, it creates performance uncertainty: users cannot be sure 145 that the performance of their connections is not being altered or 146 degrated based on how the network operator manages congestion. 147 Unfortunately, most of the solutions described below create some 148 performance uncertainty, and thus users are unlikely to view them as 149 ideal solutions, despite users' well known preference for flat-rate 150 pricing. 152 2. State-of-the-Art Building Blocks 154 Two means of learning about the resource consumption and the traffic 155 traveling through the network that are in use today are accounting 156 and deep packet inspection. 158 2.1. Accounting 160 RFC 2975 [RFC2975] describes accounting as "The collection of 161 resource consumption data for the purposes of capacity and trend 162 analysis, cost allocation, auditing, and billing.". 164 Over the years the number of information elements that can be sent 165 from an accounting client to an accounting server using standardized 166 protocols, such as RADIUS (see [RFC2866] and [RFC2865]) and Diameter 167 [RFC3588], has increased. The existence of standardized protocols 168 has allowed different AAA networks to interconnect. These protocols 169 are now used in almost every enterprise and operator network. The 170 initial accounting mechanisms envisioned a rather non-real time 171 nature in reporting resource consumption but with mechanisms like 172 like Diameter Credit Control [RFC4006] allowed real-time credit 173 control checks. 175 Although they are popular, RADIUS and Diameter are not the only 176 protocols that can be used to collect usage information and to 177 trigger responses. Other approaches, as documented in 178 [I-D.livingood-woundy-congestion-mgmt], lead to similar results. 180 2.2. Deep Packet Inspection 182 Deep packet inspection (DPI) refers to the observation and analysis 183 of traffic that passes through operator networks up to the 184 application layer. This allows operators to determine the 185 applications and/or application-layer protocols that subscribers are 186 using and respond on a per-application or per-protocol basis. 188 The process of inspecting traffic, particularly in real time, can be 189 highly performance-intensive. DPI equipment may also require 190 continous software updates to ensure that the detection engine 191 recognizes the latest protocol variants. 193 There may be a number of other factors that contribute to a network 194 operator's decision to use DPI, including potential user backlash, 195 privacy impact, and legal concerns. 197 Depending on the configuration of the device doing the inspection, 198 packet dropping/blocking and other usages might be applied. For 199 example, content sharing p2p applications maintain many simultaneous 200 TCP connections with other nodes for the purpose of simultaneous 201 downloads. An operator may, for example, limit . Certain end user 202 contracts may also allow operators to ban servers from residential 203 access. 205 3. Network Operator Responses to Congestion 207 Once they have collected congestion information using either of the 208 techniques described above or others, network operators have a number 209 of options for how to respond. For all of these options, it is up to 210 the operator to decide the breadth and depth of its response: which 211 users will be affected, the time frame in which congestion will be 212 managed, whether specific applications or protocols will be targeted, 213 and so forth. Operators can chose from both technical and pricing/ 214 contract-based options. Technical options include: 216 Wholistic traffic shaping: 218 End user contracts often provide users with a certain threshold 219 for baseline usage volume (which is typically quite high). 220 Subsequently, if consumption goes beyond the threshold, all of the 221 user's traffic is given reduced priority vis a vis other users on 222 the network. Some operators may only shape traffic during times 223 of congestion or peak usage periods (even if a user has exceeded 224 his or her baseline threshold). 226 Per-application or per-protocol shaping: 228 Network operators that can identify particular applications or 229 protocols creating congestion may decide to throttle only those 230 applications or protocols. They may also take indirect steps that 231 result in the shaping of only certain applications, such as 232 limiting the number of simultaneous TCP connection setups from a 233 single subscriber (to handle peer-to-peer traffic), or preventing 234 users from hosting servers on residential connections. An example 235 of an ISP's fair usage policy describing how it manages specific 236 protocols is included in Appendix A. 238 Class-Based Assignment: 240 In this technique users are classified into a set of classes 241 depending on their past behavior. Subsequently, their traffic is 242 treated according to their associated classes. This may prevent 243 lightweight users from feeling the effects of sharing network 244 capacity with heavy users. This mechanism requires some form of 245 packet marking to be able to differentiate light users from heavy 246 users. 248 Pricing/contract-based options include: 250 Charging for Excessive Traffic: Network operators may charge 251 users differently for traffic that exeeds a certain threshold 252 compared to the traffic that falls below the threshold. 254 Suspending or Discontinuing Contracts: In some rare cases ISPs 255 may decide to suspend or terminate the contracts of heavy 256 users. In some cases this response may be associated with a 257 security issue; when an operator recognizes a botnet-infected 258 machine generating excessive traffic, it may hotline all the 259 traffic of that particular machine to a separate network, and 260 ultimately suspend or terminate the machine's connection. In 261 some cases the same technique has been applied to users engaged 262 in heavy P2P usage, either intentionally or due to a false 263 alarm caused by a statistical traffic analysis. 265 4. New Activities 267 Following the IETF Workshop on Peer-to-Peer (P2P) Infrastructure in 268 2008 (see [RFC5594]), two working groups and one research group were 269 created that relate to the congestion issues created by peer-to-peer 270 application usage: : 272 LEDBAT (Low Extra Delay Background Transport) [ledbat] is designed 273 to keep the latency across a congested bottleneck low even as it 274 is saturated. This allows applications that send large amounts of 275 data, particularly upstream on home connections (such as peer-to- 276 peer applications) to operate without destroying the user 277 experience in interactive applications. 279 LEDBAT holds substantial promise should P2P clients adopt it 280 widely. This solution has been focused on P2P applications, and 281 its applicability to other applications, such as video using 282 H.264, is unclear. 284 ALTO (Application-Layer Traffic Optimization) [alto] aims to 285 design and specify mechanisms that will provide applications, 286 typically P2P applications, with information to perform better- 287 than-random initial peer selection to increase their performance 288 and at the same time to avoid excessive cross-domain traffic that 289 tends to be more expensive for the operator. ALTO services may 290 take different approaches at balancing factors such as maximum 291 bandwidth, minimum cross-domain traffic, or lowest cost to the 292 user, but in all cases the goal is to expose information that can 293 ameliorate the interactions between peer-to-peer usage and other 294 usages of shared networks. 296 Peer to Peer Research Group [p2prg] aims to provide a discussion 297 forum for resarchers related to all sorts of challenges presented 298 by P2P systems in general, such as P2P streaming, interconnecting 299 distinct P2P application overlays, security and privacy. Current 300 work on exposing myths about peer-to-peer filesharing 301 [I-D.irtf-p2prg-mythbustering] provides a number of references to 302 support some of the claimed benefits of ALTO solutions mechanisms, 303 such as the expected decrease in cross- domain traffic. 305 5. Summary 307 High-consuming users are a reality. Operators that would like to 308 counteract the impact of heavy users on their networks have a fair 309 number of tools at their disposal. These tools may allow operators 310 to identify heavy users, collect performance and usage indications, 311 and choose from a variety of mitigating steps depending on the 312 operator's preferred business practices. Subscriber-specific 313 information, including policies, resource consumption information, 314 and details about the current network attachment point, may be 315 available in accounting servers. Information about the network 316 topology and the state of particular topology elements may be 317 available in the network management infrastructure. Solution 318 approaches similar to [I-D.livingood-woundy-congestion-mgmt] have 319 demonstrated one way of taking congestion information into 320 consideration. 322 The currently available mechanisms for identifying and mitigating 323 congestion largely run wholly within an operator's network and 324 without a lot of information exchange about congestion information to 325 or from end hosts or other network operators. Exposing this 326 information may allow end devices to make more informed decisions 327 (although policy enforcement would still be required by the 328 operator). 330 The collection of congestion information poses the challenge of 331 deciding where in the network to put the metering agents to ensure 332 that enough information is collected at the right point in time. 333 Distributed collection and the correlation of the information across 334 different nodes is a complex task. An approach that collects this 335 congestion information along the path of the data packet (via inband 336 signaling) would simplify this task. Regardless of the technical 337 solution utilized for collecting information, certain users will 338 undoubtedly observe the effects of decisions that operators make 339 about how to handle congestion. Allowing users to understand these 340 decisions will be crucial and having a channel to send feedback to 341 the end device and/or subscriber would be a helpful step towards 342 increased transparency. 344 6. Security Considerations 346 This document highlights approaches for dealing with high-consuming 347 network users and all of them raise security and privacy concerns. 348 It does not introduce new mechanisms. The security considerations 349 for the existing mechanisms mentioned apply. 351 7. IANA Considerations 353 This document does not require actions by IANA. 355 8. Acknowledgments 357 The authors would like to thank Alan DeKok, Jens-Peter Haack, 358 Alexander Bachmutsky, Jonne Soininen, Joachim Charzinski, Hannu 359 Flinck, Joachim Kross, Jouni Korhonen, Mayutan Arumaithurai, Richard 360 Woundy, Daniel Correa Lobato, Luca Caviglione, Tommy Lindgren, Lars 361 Eggert, for their time to discuss the topic. Additionally, we would 362 like to thank Marcin Matuszewski for his help with the P2P 363 infrastructure workshop paper (since it was used as a starting point 364 for the work on this memo). 366 9. References 368 9.1. Normative References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, March 1997. 373 9.2. Informative References 375 [I-D.irtf-p2prg-mythbustering] 376 Marocco, E., Fusco, A., Rimac, I., and V. Gurbani, 377 "Improving Peer Selection in Peer-to-peer Applications: 378 Myths vs. Reality", draft-irtf-p2prg-mythbustering-00 379 (work in progress), August 2009. 381 [I-D.livingood-woundy-congestion-mgmt] 382 Bastian, C., Klieber, T., Livingood, J., Mills, J., and R. 383 Woundy, "Comcast's Protocol-Agnostic Congestion Management 384 System", draft-livingood-woundy-congestion-mgmt-01 (work 385 in progress), September 2009. 387 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 388 "Remote Authentication Dial In User Service (RADIUS)", 389 RFC 2865, June 2000. 391 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 393 [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to 394 Accounting Management", RFC 2975, October 2000. 396 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 397 Aboba, "Dynamic Authorization Extensions to Remote 398 Authentication Dial In User Service (RADIUS)", RFC 3576, 399 July 2003. 401 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 402 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 404 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 405 Loughney, "Diameter Credit-Control Application", RFC 4006, 406 August 2005. 408 [RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop 409 on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", 410 RFC 5594, July 2009. 412 [alto] "", 413 . 415 [ledbat] "", 416 . 418 [p2prg] "", . 420 [traffic] Cho, K., Fukuda, K., Kato, H., and A. Kato, "The impact 421 and implications of the growth in residential user-to-user 422 traffic", SIGCOMM Comput. Commun. Rev. 36, 2006. 424 [traffic2] 425 Cho, K., Fukuda, K., Esaki, H., and A. Kato, "Observing 426 slow crustal movement in residential user traffic, in 427 International Conference On Emerging Networking 428 Experiments And Technologies, Proceedings of the 2008 ACM 429 CoNEXT Conference, Madrid, Spain, Article No. 12", , 430 2008. 432 Appendix A. Example Policy Statement 434 A.1. Fair Usage Policy 436 A.1.1. What is the Fair Usage Policy? 438 The Fair Usage Policy is designed to ensure that the service received 439 by the vast majority of our customers is not negatively impacted 440 because of extremely heavy usage by a very small minority of 441 customers. This is why ISP X continuously monitors network 442 performance and may restrict the speed available to very heavy users 443 during peak time. This applies to customers on all Options. Note if 444 you are a heavy user we will only restrict your speed, service will 445 not be stopped so ability to upload and download remains. No 446 restrictions will be imposed outside of the peak times. Only a very 447 small minority of customers will ever be affected by this (less than 448 1 %). 450 A.1.2. How do I know I'm a very heavy user? 452 There is no hard and fast usage limit that determines if you are a 453 heavy user as the parameters that determine heavy use vary with the 454 demands placed on the network at that given time. If you have a 455 query about fair usage related restrictions on your line please call 456 us. 458 A.1.3. I have Contract Option 3, does the Fair Usage Policy apply to 459 me? 461 Yes, the Fair Usage Policy applies to all customers on all Options, 462 including Option 3. Option 3 allows unlimited downloads and uploads 463 inclusive of the monthly rental price, so you will not be charged for 464 over-use, however this does not preclude ISP X from restricting your 465 speed at peak times if you are a heavy user. If you are an Option 3 466 heavy user this does not prevent you from continuing to use your 467 service, nor does it cost you any more but it ensures that you do not 468 negatively impact the majority of our customers who share the 469 available bandwidth with you. 471 A.1.4. Peer to Peer (P2P) 473 A.1.4.1. I'm noticing slower P2P speeds at peak times even though I'm 474 not a very heavy user, why is this? 476 P2P is the sharing and delivery of files amongst groups of people who 477 are logged on to a file sharing network. P2P consumes a significant 478 and highly disproportionate amount of bandwidth when in use even by 479 small numbers of users. 481 This is why we have a peak time policy where we limit P2P speeds to 482 manage the amount of bandwidth that is used by this application in 483 particular. 485 Without these limits all our customers using their broadband service 486 at peak times would suffer, regardless of whether they are using P2P 487 or not. It's important to remember that P2P isn't a time-critical 488 application so if you do need to download large files we advise you 489 to do this at off-peak times when no restrictions are placed, not 490 only will you be able to download faster but your usage will not 491 negatively impact other users. 493 A.1.4.2. Does this mean I can't use Peer-to-Peer (P2P) applications? 495 No, we are not stopping you from using any P2P service, P2P will just 496 be slowed down at peak times. Again, P2P is not generally a time- 497 sensitive application. 499 Authors' Addresses 501 Hannes Tschofenig 502 Nokia Siemens Networks 503 Linnoitustie 6 504 Espoo FIN-02600 505 Finland 507 Phone: +358 (50) 4871445 508 Email: Hannes.Tschofenig@gmx.net 509 URI: http://www.tschofenig.priv.at 511 Alissa Cooper 512 Center for Democracy & Technology 513 1634 I Street NW, Suite 1100 514 Washington, DC 515 USA 517 Email: acooper@cdt.org