idnits 2.17.00 (12 Aug 2021) /tmp/idnits301/draft-tschofenig-conex-ps-00.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 19, 2009) is 4597 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 362, 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 (~~), 4 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 22, 2010 Center for Democracy & 6 Technology 7 October 19, 2009 9 Congestion Exposure Problem Statement 10 draft-tschofenig-conex-ps-00.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 22, 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 availability of broadband connections together with flat-rate 49 pricing has made new types of peer-to-peer applications possible. 50 From an Internet evolution and end user value point of view this is 51 very exciting. As a consequence, an increase of user-to-user traffic 52 was observable all around the world over the last few years. With 53 the usage of p2p systems the observation can be made that a certain 54 group of users, called high-consuming users, decided to use their 55 flat-rate contract excessively. This in turn seems to have caused 56 network operators to take actions. 58 This document illustrates a couple of techniques used by operators 59 today to deal with excessive bandwidth usage. More information can 60 improve the decision making process. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. State-of-the-Art Building Blocks . . . . . . . . . . . . . . . 5 66 2.1. Means of Identifying the Causes of Congestion . . . . . . 5 67 2.2. Potential Actions Operators might take in Response . . . . 6 68 3. New Activities . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 76 Appendix A. Example Policy Statement . . . . . . . . . . . . . . 15 77 A.1. Fair Usage Policy . . . . . . . . . . . . . . . . . . . . 15 78 A.1.1. What is the Fair Usage Policy? . . . . . . . . . . . . 15 79 A.1.2. How do I know I'm a very heavy user? . . . . . . . . . 15 80 A.1.3. I have Contract Option 3, does the Fair Usage 81 Policy apply to me? . . . . . . . . . . . . . . . . . 15 82 A.1.4. Peer to Peer (P2P) . . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 In 2006 K. Cho et al. [traffic] published a paper about the growth of 88 residential user-to-user traffic in Japan that indicates '... a small 89 number of users dictate the overall behavior; 4 % of high-consuming 90 users account for 75 % of the inbound volume, and the fiber users 91 account for 86 % of the inbound volume.'. The same paper also 92 indicates a substantial increase in traffic growth, namely 37 % per 93 year according, and not just a different distribution of traffic 94 among the users. At that time 63 % of the residential traffic volume 95 is contributed by user-to-user traffic. 97 These numbers itself do not represent a problem as by themself and do 98 not necessarily lead to congestion. However, some operators very 99 likely had different expectations about the growth rates and traffic 100 consumption of individual users and statistics (used for their 101 pricing models) did not work out too well for them. The profit 102 margins for Internet access are quite slim due to fierce competition. 103 This puts a lot of pressure on operators to deal with these high- 104 consuming users who cost them a lot of money. Finally, some 105 broadband networks may not have the ideal characteristics (such as 106 the topology for routing traffic) for user-to-user traffic (e.g., 107 Cable Networks). 109 Congestion is often mentioned in this context and as stated in RFC 110 5594 [RFC5594] "... congestion can be viewed merely as a 111 manifestation of cost. An ISP that invests in capacity could be 112 considered to be paying to relieve congestion. Or, if subscribers 113 are charged for congesting the network, then cost and congestion 114 could be viewed as one and the same. The distinction between them 115 may thus be artificial.". 117 To summarize in a simplistic way, those who produce a lot of traffic 118 cost a lot. 120 Operators are now facing a range of options, see sections below, that 121 can be taken and there is a tradeoff between what is allowed (legally 122 and from a public relation point of view) and what is useful from a 123 performance point of view. The latter aspect can be seen from the 124 point of view of a device performance (as many of the mechanisms 125 actually slow down the forwarding performance quite a bit) and 126 consequently a cost challenge. 128 The existence of flat rate pricing contributes to some of the 129 problems since the bandwidth usage in total needs to be covered by 130 the money obtained from broadband customers but the usage of 131 individual users is not reflected in the amount. As such, users that 132 rarely utilize the network pay the same amount as someone who uses 133 P2p filesharing excessively. 135 However, from a psychological point of view humans tend to strive to 136 avoid uncertainty and hence offerings that reduced uncertainty. For 137 a user there are essentially two aspects to worry about 139 o Uncertainty in the bill: unpredicable costs that make planning 140 difficult. 142 o Uncertainty in the performance: performance degradation as part of 143 the actions being taken 145 True flat rate pricing avoids uncertainty in the bill. 146 Unfortunately, most of the solutions described below lead to some 147 uncertainty and thereby increase unhappyness of customers. 149 2. State-of-the-Art Building Blocks 151 2.1. Means of Identifying the Causes of Congestion 153 RFC 2975 [RFC2975] describes accounting as "The collection of 154 resource consumption data for the purposes of capacity and trend 155 analysis, cost allocation, auditing, and billing.". 157 Over the years the number of information elements that can be sent 158 from an accounting client to an accounting server using standardized 159 protocols, such as RADIUS (see [RFC2866] and [RFC2865]) and Diameter 160 [RFC3588], has increased. The fact that standardized protocols have 161 been available allowed different AAA networks to be interconnected 162 and their usage can be found in almost every enterprise and operator 163 network. The initial accounting mechanisms envisioned a rather non- 164 real time nature in reporting resource consumption but with 165 mechanisms like like Diameter Credit Control [RFC4006] allowed real- 166 time credit control checks. 168 It has to be noted that RADIUS and Diameter are not the only 169 protocols that can be used to collect usage information and to 170 trigger certain actions, even they are fairly popular. Other 171 approaches, as documented in [I-D.livingood-woundy-congestion-mgmt], 172 lead to similar results. 174 Deep packet inspection refers to inspecting traffic that passes 175 through the operators networks up to the application layer. 176 Depending on the configuration of the device traffic shaping, packet 177 dropping/blocking and other usages might be applied. For example, 178 content sharing p2p applications maintain many simultaneous TCP 179 connections with other nodes for the purpose of simultaneous 180 downloads. An operator may, for example, limit the number of 181 connection setups from a single subscriber. Certain end user 182 contracts may also allow operators to ban servers from residential 183 access. 185 Determining the type of application that a subscriber is running was 186 seen as necessary to throttle only certain applications, instead of 187 impacting the full range of traffic a subscriber is using. A side- 188 effect is the additional investment for the device and operational 189 costs. The process of inspecting traffic is performance intensive 190 and continous software updates are necessary to ensure that the 191 detection engine recognizes the latest protocol variants. 192 Additionally, the attempt to selectively deal with applications (even 193 though these applications might be the reason for the high traffic 194 volume) has not been received well by the users. 196 2.2. Potential Actions Operators might take in Response 198 What actions are taken based on the collected information and in what 199 time frame is largely left to the choice of those who run the 200 infrastructure. In the context of this discussion the collected 201 information may be used to charge the user per volume, per time and 202 in various different combinations. Additionally, the RADIUS and 203 Diameter allow the server side with a server-initiated message (see 204 Change of Authorization in [RFC3576], and the functionality provided 205 in the Diameter Base specification [RFC3588]) to push decisions to 206 the AAA clients, typically edge nodes, acting as enforcement nodes. 207 These decisions include actions like shaping or packet marking. 209 Shaping: End user contracts often offer a combination of 'flat-rate' 210 scheme whereby a fixed price tariff is used up to a certain usage 211 volume (typically quite high for regular usage). Subsequently, if 212 the consumption goes beyond a certain threshold then the entire 213 traffic is given lower priority and potentially shaped. 215 In many countries operators have to offer a clear description 216 of the service they offer and since the term 'flat-rate' is 217 already associated with a certain meaning the term 'Unlimited 218 Data Rate' is often used for this type of service. Contracts 219 typically contain statements that allow certain actions to be 220 taken. An example of such a fair use statement can be found in 221 Appendix A. 223 Note that traffic shaping is often only applied to high-consuming 224 users (since they are known based on the accounting procedures) or 225 the effect becomes only visible during peak hours when the network 226 fills up. 228 Class-Based Assignment: In this technique users are classified into 229 a set of classes depending on their past behavior. Subsequently, 230 the traffic is treated according to the associated class. It is 231 ensured that the traffic of lightweight users, users that really 232 rarely use their Internet connection, cannot be pushed away by 233 heavy users. This mechanism again requires some form of DiffServ 234 marking to be in place. 236 Charging for Excessive Traffic: As a possible action a user might 237 get charged differently for traffic that exeeds a certain 238 threshold compared to the traffic that falls within the agreed 239 limits. 241 Discontinuing Contracts: In some rare cases ISP also decided to cut 242 connectivity under certain condition. In fact this might be 243 justified in certain cases. For example, in case of new botnets 244 malware distribution when the operator recognizes an infected 245 machine and hotlines the entire traffic of that particular machine 246 to a separate network and, like in WLAN hotspots, HTTP traffic is 247 intercepted to display further information. In some cases the 248 same technique has been applied with excessive usage of P2P 249 traffic, either intentionally or due to a false alarm caused by a 250 statistical traffic analysis technique. 252 In France the HADOPI law adopted in parliament that allowed an 253 'independent authority' to punish copyright violators with a 254 temporary suspension of their Internet access has raised 255 discussions within Europe about the fundamental right to 256 'communicate and express' and its applicability to the Internet 257 access. Although this discussion is still ongoing the French 258 Supreme Court had striked down portions of the law arguing that 259 any restriction of such a right can only be decided by a judge. 261 3. New Activities 263 In response to the P2P infrastructure workshop in 2008 (with a 264 summary documented [RFC5594]) two working groups and one research 265 group has been created that focus on a certain area of the 266 application space: 268 LEDBAT (Low Extra Delay Background Transport) [ledbat] is designed 269 to allow to keep the latency across the congested bottleneck low 270 even as it is saturated. This allows applications that send large 271 amounts of data, particularly upstream on home connections, such 272 as peer-to-peer application, to operate without destroying the 273 user experience in interactive applications. 275 LEDBAT is a promising approach when applied widely in P2P clients. 276 This solution has been focused P2P applications, and its 277 applicability to other applications, such as video using H.264, is 278 unclear. 280 ALTO (Application-Layer Traffic Optimization) [alto] aims to 281 design and specify mechanisms that will provide applications, 282 typically P2P applications, with information to perform better- 283 than-random initial peer selection to increase their performance 284 and at the same time to avoid excessive cross-domain traffic that 285 tends to be more expensive for the operator. For legal content 286 ALTO mechanisms with the ability for ISPs to deploy proxies appear 287 to be a viable solution. However, a lot of the content being 288 distributed in P2P filesharing networks today is not legal and 289 caching such content by operators could turn out problematic for 290 them. 292 Peer to Peer Research Group [p2prg] aims to provide a discussion 293 forum for resarchers related to all sorts of challenges of P2P 294 systems in general, such as P2P streaming, interconnecting 295 distinct P2P application overlays, security and privacy, etc. 296 [I-D.irtf-p2prg-mythbustering] provides a number of literature 297 references to support some of the claimed benefits of ALTO 298 solutions mechanisms, such as the expected decrease in cross- 299 domain traffic. 301 4. Summary 303 Heavy users are a reality. Operators that would like to counteract 304 the impact of heavy users on their networks have a fair number of 305 tools at their disposal. These tools may allow operators to identify 306 heavy users, collect performance and usage indications, and choose 307 from a variety of mitigating steps depending on the operator's 308 preferred business practices. Subscriber-specific information, 309 including policies, resource consumption information, and details 310 about the current network attachment point, may be available in 311 accounting servers. Information about the network topology and the 312 state of particular topology elements may be available in the network 313 management infrastructure. Solution approaches similar to 314 [I-D.livingood-woundy-congestion-mgmt] have demonstrated one way of 315 taking congestion information into consideration. 317 The currently available mechanisms for identifying and mitigating 318 congestion largely run wholly within an operator's network and 319 without a lot of information exchange about congestion information to 320 or from end hosts or other network operators. Exposing this 321 information may allow end devices to make more informed decisions 322 (although policy enforcement would still be required by the 323 operator). 325 The collection of congestion information poses the challenge of 326 deciding where in the network to put the metering agents to ensure 327 that enough information is collected at the right point in time. 328 Distributed collection and the correlation of the information across 329 different nodes is a complex task. An approach that collects this 330 congestion information along the path of the data packet (via inband 331 signaling) would simplify this task. Regardless of the technical 332 solution utilized for collecting information, certain users will 333 undoubtedly observe the effects of decisions that operators make 334 about how to handle congestion. Allowing users to understand these 335 decisions will be crucial and having a channel to send feedback to 336 the end device and/or subscriber would be a helpful step towards 337 increased transparency. 339 5. Security Considerations 341 This document highlights approaches for dealing with heavy network 342 usage and all of them raise security and privacy concerns. This 343 document does, however, not introduce new mechanism and hence the 344 reader is referred to the description of the respective mechanism. 346 6. IANA Considerations 348 This document does not require actions by IANA. 350 7. Acknowledgments 352 The authors would like to thank Alan DeKok, Jens-Peter Haack, Jouni 353 Korhonen, Tommy Lindgren, Lars Eggert, for their time to discuss the 354 topic. Additionally, we would like to thank Marcin Matuszewski for 355 his help with the P2P infrastructure workshop paper (as it was used 356 as a starting point). 358 8. References 360 8.1. Normative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, March 1997. 365 8.2. Informative References 367 [I-D.irtf-p2prg-mythbustering] 368 Marocco, E., Fusco, A., Rimac, I., and V. Gurbani, 369 "Improving Peer Selection in Peer-to-peer Applications: 370 Myths vs. Reality", draft-irtf-p2prg-mythbustering-00 371 (work in progress), August 2009. 373 [I-D.livingood-woundy-congestion-mgmt] 374 Bastian, C., Klieber, T., Livingood, J., Mills, J., and R. 375 Woundy, "Comcast's Protocol-Agnostic Congestion Management 376 System", draft-livingood-woundy-congestion-mgmt-01 (work 377 in progress), September 2009. 379 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 380 "Remote Authentication Dial In User Service (RADIUS)", 381 RFC 2865, June 2000. 383 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 385 [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to 386 Accounting Management", RFC 2975, October 2000. 388 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 389 Aboba, "Dynamic Authorization Extensions to Remote 390 Authentication Dial In User Service (RADIUS)", RFC 3576, 391 July 2003. 393 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 394 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 396 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 397 Loughney, "Diameter Credit-Control Application", RFC 4006, 398 August 2005. 400 [RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop 401 on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", 402 RFC 5594, July 2009. 404 [alto] "", 405 . 407 [ledbat] "", 408 . 410 [p2prg] "", . 412 [traffic] Cho, K., Fukuda, K., Kato, H., and A. Kato, "The impact 413 and implications of the growth in residential user-to-user 414 traffic", SIGCOMM Comput. Commun. Rev. 36, 2006. 416 Appendix A. Example Policy Statement 418 A.1. Fair Usage Policy 420 A.1.1. What is the Fair Usage Policy? 422 The Fair Usage Policy is designed to ensure that the service received 423 by the vast majority of our customers is not negatively impacted 424 because of extremely heavy usage by a very small minority of 425 customers. This is why ISP X continuously monitors network 426 performance and may restrict the speed available to very heavy users 427 during peak time. This applies to customers on all Options. Note if 428 you are a heavy user we will only restrict your speed, service will 429 not be stopped so ability to upload and download remains. No 430 restrictions will be imposed outside of the peak times. Only a very 431 small minority of customers will ever be affected by this (less than 432 1 %). 434 A.1.2. How do I know I'm a very heavy user? 436 There is no hard and fast usage limit that determines if you are a 437 heavy user as the parameters that determine heavy use vary with the 438 demands placed on the network at that given time. If you have a 439 query about fair usage related restrictions on your line please call 440 us. 442 A.1.3. I have Contract Option 3, does the Fair Usage Policy apply to 443 me? 445 Yes, the Fair Usage Policy applies to all customers on all Options, 446 including Option 3. Option 3 allows unlimited downloads and uploads 447 inclusive of the monthly rental price, so you will not be charged for 448 over-use, however this does not preclude ISP X from restricting your 449 speed at peak times if you are a heavy user. If you are an Option 3 450 heavy user this does not prevent you from continuing to use your 451 service, nor does it cost you any more but it ensures that you do not 452 negatively impact the majority of our customers who share the 453 available bandwidth with you. 455 A.1.4. Peer to Peer (P2P) 457 A.1.4.1. I'm noticing slower P2P speeds at peak times even though I'm 458 not a very heavy user, why is this? 460 P2P is the sharing and delivery of files amongst groups of people who 461 are logged on to a file sharing network. P2P consumes a significant 462 and highly disproportionate amount of bandwidth when in use even by 463 small numbers of users. 465 This is why we have a peak time policy where we limit P2P speeds to 466 manage the amount of bandwidth that is used by this application in 467 particular. 469 Without these limits all our customers using their broadband service 470 at peak times would suffer, regardless of whether they are using P2P 471 or not. It's important to remember that P2P isn't a time-critical 472 application so if you do need to download large files we advise you 473 to do this at off-peak times when no restrictions are placed, not 474 only will you be able to download faster but your usage will not 475 negatively impact other users. 477 A.1.4.2. Does this mean I can't use Peer-to-Peer (P2P) applications? 479 No, we are not stopping you from using any P2P service, P2P will just 480 be slowed down at peak times. Again, P2P is not generally a time- 481 sensitive application. 483 Authors' Addresses 485 Hannes Tschofenig 486 Nokia Siemens Networks 487 Linnoitustie 6 488 Espoo FIN-02600 489 Finland 491 Phone: +358 (50) 4871445 492 Email: Hannes.Tschofenig@gmx.net 493 URI: http://www.tschofenig.priv.at 495 Alissa Cooper 496 Center for Democracy & Technology 497 1634 I Street NW, Suite 1100 498 Washington, DC 499 USA 501 Email: acooper@cdt.org