idnits 2.17.1 draft-ietf-conex-concepts-uses-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (November 15, 2010) is 4904 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Fairer-faster' is defined on line 746, but no explicit reference was found in the text == Unused Reference: 'Malice' is defined on line 766, but no explicit reference was found in the text == Unused Reference: 'Re-Feedback' is defined on line 800, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ledbat-congestion-01 -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CONEX B. Briscoe 3 Internet-Draft BT 4 Intended status: Informational R. Woundy 5 Expires: May 19, 2011 Comcast 6 T. Moncaster, Ed. 7 Moncaster.com 8 J. Leslie, Ed. 9 JLC.net 10 November 15, 2010 12 ConEx Concepts and Use Cases 13 draft-ietf-conex-concepts-uses-00 15 Abstract 17 Internet Service Providers (operators) are facing problems where 18 localized congestion prevents full utilization of the path between 19 sender and receiver at today's "broadband" speeds. Operators desire 20 to control this congestion, which often appears to be caused by a 21 small number of users consuming a large amount of bandwidth. 22 Building out more capacity along all of the path to handle this 23 congestion can be expensive and may not result in improvements for 24 all users so network operators have sought other ways to manage 25 congestion. The current mechanisms all suffer from difficulty 26 measuring the congestion (as distinguished from the total traffic). 28 The ConEx Working Group is designing a mechanism to make congestion 29 along any path visible at the Internet Layer. This document 30 describes example cases where this mechanism would be useful. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 19, 2011. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Congestion Management . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Existing Approaches . . . . . . . . . . . . . . . . . . . 7 70 4. Exposing Congestion . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. ECN - a Step in the Right Direction . . . . . . . . . . . 9 72 5. ConEx Use Cases . . . . . . . . . . . . . . . . . . . . . . . 10 73 5.1. ConEx as a basis for traffic management . . . . . . . . . 10 74 5.2. ConEx to incentivise scavenger transports . . . . . . . . 10 75 5.3. Accounting for Congestion Volume . . . . . . . . . . . . . 11 76 5.4. ConEx as a form of differential QoS . . . . . . . . . . . 11 77 5.5. Partial vs. Full Deployment . . . . . . . . . . . . . . . 12 78 6. Other issues . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 6.1. Congestion as a Commercial Secret . . . . . . . . . . . . 13 80 6.2. Information Security . . . . . . . . . . . . . . . . . . . 14 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 The growth of "always on" broadband connections, coupled with the 91 steady increase in access speeds [OfCom], have caused unforeseen 92 problems for network operators and users alike. Users are 93 increasingly seeing congestion at peak times and changes in usage 94 patterns (with the growth of real-time streaming) simply serve to 95 exacerbate this. Operators want all their users to see a good 96 service but are unable to see where congestion problems originate. 97 But congestion results from sharing network capacity with others, not 98 merely from using it. In general, today's "DSL" and cable-internet 99 users cannot "cause" congestion in the absence of competing traffic. 100 (Wireless operators and cellular internet have different tradeoffs 101 which we will not discuss here.) 103 Congestion generally results from the interaction of traffic from one 104 network operator's users with traffic from other users. The tools 105 currently available don't allow an operator to identify which traffic 106 contributes most to the congestion and so they are powerless to 107 properly control it. 109 While building out more capacity to handle increased traffic is 110 always good, the expense and lead-time can be prohibitive, especially 111 for network operators that charge flat-rate feeds to subscribers and 112 are thus unable to charge heavier users more for causing more 113 congestion [BB-incentive]. For an operator facing congestion caused 114 by other operators' networks, building out its own capacity is 115 unlikely to solve the congestion problem. Operators are thus facing 116 increased pressure to find effective solutions to dealing with the 117 increasing bandwidth demands of all users. 119 The growth of "scavenger" behaviour (e.g. [LEDBAT]) helps to reduce 120 congestion, but can actually make the problem less tractable. These 121 users are trying to make good use of the capacity of the path while 122 minimising their own costs. Thus, users of such services may show 123 very heavy total traffic up until the moment congestion is detected 124 (at the Transport Layer), but then will immediately back off. 125 Monitoring (at the Internet Layer) cannot detect this congestion 126 avoidance if the congestion in question is in a different domain 127 further along the path; and must treat such users as congestion- 128 causing users. 130 The ConEx working group proposes that Internet Protocol (IP) packets 131 will carry additional ConEx information. The exact protocol details 132 are not described in this document, but the ConEx information will be 133 sufficient to allow any node in the network to see how much 134 congestion is attributable to a given traffic flow. See 135 [ConEx-Abstract-Mech] for further details. 137 Changes from previous drafts (to be removed by the RFC Editor): 139 From draft-moncaster-conex-concepts-uses-02 to 140 draft-ietf-conex-concepts-uses-00 (per decisions of working group): 142 Removed section on DDoS mitigation use case. 144 Removed appendix on ConEx Architectural Elements. PLEASE NOTE: 145 Alignment of terminology with the Abstract Mechanism draft has 146 been deferred to the next version. 148 From draft-moncaster-conex-concepts-uses-01 to 149 draft-moncaster-conex-concepts-uses-02: 151 Updated document to take account of the new Abstract Mechanism 152 draft [ConEx-Abstract-Mech]. 154 Updated the definitions section. 156 Removed sections on Requirements and Mechanism. 158 Moved section on ConEx Architectural Elements to appendix. 160 Minor changes throughout. 162 From draft-moncaster-conex-concepts-uses-00 to 163 draft-moncaster-conex-concepts-uses-01: 165 Changed end of Abstract to better reflect new title 167 Created new section describing the architectural elements of 168 ConEx. Added Edge Monitors and Border Monitors (other elements 169 are Ingress, Egress and Border Policers). 171 Extensive re-write of Section 5 partly in response to suggestions 172 from Dirk Kutscher 174 Improved layout of Section 2 and added definitions of Whole Path 175 Congestion, ConEx-Enabled and ECN-Enabled. Re-wrote definition of 176 Congestion Volume. Renamed Ingress and Egress Router to Ingress 177 and Egress Node as these nodes may not actually be routers. 179 Improved document structure. Merged sections on Exposing 180 Congestion and ECN. 182 Added new section on ConEx requirements with a ConEx Issues 183 subsection. Text for these came from the start of the old ConEx 184 Use Cases section 186 Added a sub-section on Partial vs Full Deployment Section 5.5 188 Added a discussion on ConEx as a Business Secret Section 6.1 190 From draft-conex-mechanism-00 to 191 draft-moncaster-conex-concepts-uses-00: 193 Changed filename to draft-moncaster-conex-concepts-uses. 195 Changed title to ConEx Concepts and Use Cases. 197 Chose uniform capitalisation of ConEx. 199 Moved definition of Congestion Volume to list of definitions. 201 Clarified mechanism section. Changed section title. 203 Modified text relating to conex-aware policing and policers (which 204 are NOT defined terms). 206 Re-worded bullet on distinguishing ConEx and non-ConEx traffic in 207 Section 5. 209 2. Definitions 211 In this section we define a number of terms that are used throughout 212 the document. The key definition is that of congestion, which has a 213 number of meanings depending on context. The definition we use in 214 this document is based on the definition in [Padhye] where congestion 215 is viewed as a probability that a packet will be dropped. This list 216 of definitions is supplementary to that in [ConEx-Abstract-Mech]. 218 Congestion: Congestion is a measure of the probability that a packet 219 will be marked or dropped as it traverses a queue. 221 flow: a series of packets from a single sender to a single receiver 222 that are treated by that sender as belonging to a single stream 223 for the purposes of congestion control. NB in general this is not 224 the same as the aggregate of all traffic between the sender and 225 receiver. 227 Congestion-rate: For any granularity of traffic (packet, flow, 228 aggregate, etc.), the instantaneous rate of traffic discarded or 229 marked due to congestion. Conceptually, the instantaneous bit- 230 rate of the traffic multiplied by the instantaneous congestion it 231 is experiencing. 233 Congestion-volume: For any granularity of traffic (packet, flow, 234 aggregate, etc.), the volume of bytes dropped or marked in a given 235 period of time. Conceptually, congestion-rate multipled by time. 237 Upstream Congestion: the accumulated level of congestion experienced 238 by a traffic flow thus far along its path. In other words, at any 239 point the Upstream Congestion is the accmulated level of 240 congestion the traffic flow has experienced as it travels from the 241 sender to that point. At the receiver this is equivalent to the 242 end-to-end congestion level that (usually) is reported back to the 243 sender. 245 Downstream Congestion: the level of congestion a flow of traffic is 246 expected to experience on the remainder of its path. In other 247 words, at any point the Downstream Congestion is the level of 248 congestion the traffic flow is yet to experience as it travels 249 from that point to the receiver. 251 Ingress: the first node a packet traverses that is outside the 252 source's own network. In a domestic network that will be the 253 first node downstream from the home access equipment. In an 254 enterprise network this is the provider edge router. 256 Egress: the last node a packet traverses before reaching the 257 receiver's network. 259 ConEx-enabled: Any piece of equipment (end-system, router, tunnel 260 end-point, firewall, policer, etc) that complies with the core 261 ConEx protocol, which is to be defined by the ConEx working group. 262 By extension a ConEx-enabled network is a network whose edge nodes 263 are all ConEx-enabled. 265 3. Congestion Management 267 Since 1988 the Internet architecture has made congestion management 268 the responsibility of the end-systems. The network signals 269 congestion to the receiver, the receiver feeds this back to the 270 sender and the sender is expected to try and reduce the traffic it 271 sends. 273 Any network that is persistently highly congested is inefficient. 274 However the total absence of congestion is equally bad as it means 275 there is spare capacity in the network that hasn't been used. The 276 long-standing aim of congestion control has been to find the point 277 where these two things are in balance. 279 Over recent years, some network operators have come to the view that 280 end-system congestion management is insufficient. Because of the 281 heuristics used by TCP, a relatively small number of end-machines can 282 get a disproportionately high share of network resources. They have 283 sought to "correct" this perceived problem by using middleboxes that 284 try and reduce traffic that is causing congestion or by artificially 285 starving some traffic classes to create stronger congestion signals. 287 3.1. Existing Approaches 289 The authors have chosen not to exhaustively list current approaches 290 to congestion management. Broadly these approaches can be divided 291 into those that happen at Layer 3 of the OSI model and those that use 292 information gathered from higher layers. In general these approaches 293 attempt to find a "proxy" measure for congestion. Layer 3 approaches 294 include: 296 o Volume accounting -- the overall volume of traffic a given user or 297 network sends is measured. Users may be subject to an absolute 298 volume cap (e.g. 10Gbytes per month) or the "heaviest" users may 299 be sanctioned in some manner. 301 o Rate measurement -- the traffic rate per user or per network can 302 be measured. The absolute rate a given user sends at may be 303 limited at peak hours or the average rate may be used as the basis 304 for inter-network billing. 306 Higher layer approaches include: 308 o Bottleneck rate policing -- bottleneck flow rate policers aim to 309 share the available capacity at a given bottleneck between all 310 concurrent users. 312 o DPI and application rate policing -- deep packet inspection and 313 other techniques can be used to determine what application a given 314 traffic flow is associated with. Operators may then use this 315 information to rate-limit or otherwise sanction certain 316 applications at peak hours. 318 All of these current approaches suffer from some general limitations. 319 First, they introduce performance uncertainty. Flat-rate pricing 320 plans are popular because users appreciate the certainty of having 321 their monthly bill amount remain the same for each billing period, 322 allowing them to plan their costs accordingly. But while flat-rate 323 pricing avoids billing uncertainty, it creates performance 324 uncertainty: users cannot know whether the performance of their 325 connection is being altered or degraded based on how the network 326 operator manages congestion. 328 Second, none of the approaches is able to make use of what may be the 329 most important factor in managing congestion: the amount that a given 330 endpoint contributes to congestion on the network. This information 331 simply is not available to network nodes, and neither volume nor rate 332 nor application usage is an adequate proxy for congestion volume, 333 because none of these metrics measures a user or network's actual 334 contribution to congestion on the network. 336 Finally, none of these solutions accounts for inter-network 337 congestion. Mechanisms may exist that allow an operator to identify 338 and mitigate congestion in their own network, but the design of the 339 Internet means that only the end-hosts have full visibility of 340 congestion information along the whole path. ConEx allows this 341 information to be visible to everyone on the path and thus allows 342 operators to make better-informed decisions about controlling 343 traffic. 345 4. Exposing Congestion 347 We argue that current traffic-control mechanisms seek to control the 348 wrong quantity. What matters in the network is neither the volume of 349 traffic nor the rate of traffic: it is the contribution to congestion 350 over time -- congestion means that your traffic impacts other users, 351 and conversely that their traffic impacts you. So if there is no 352 congestion there need not be any restriction on the amount a user can 353 send; restrictions only need to apply when others are sending traffic 354 such that there is congestion. 356 For example, an application intending to transfer large amounts of 357 data could use a congestion control mechanism like [LEDBAT] to reduce 358 its transmission rate before any competing TCP flows do, by detecting 359 an increase in end-to-end delay (as a measure of impending 360 congestion). However such techniques rely on voluntary, altruistic 361 action by end users and their application providers. Operators can 362 neither enforce their use nor avoid penalizing them for congestion 363 they avoid. 365 The Internet was designed so that end-hosts detect and control 366 congestion. We argue that congestion needs to be visible to network 367 nodes as well, not just to the end hosts. More specifically, a 368 network needs to be able to measure how much congestion any 369 particular traffic expects to cause between the monitoring point in 370 the network and the destination ("rest-of-path congestion"). This 371 would be a new capability. Today a network can use Explicit 372 Congestion Notification (ECN) [RFC3168] to detect how much congestion 373 the traffic has suffered between the source and a monitoring point, 374 but not beyond. This new capability would enable an ISP to give 375 incentives for the use of LEDBAT-like applications that seek to 376 minimise congestion in the network whilst restricting inappropriate 377 uses of traditional TCP and UDP applications. 379 So we propose a new approach which we call Congestion Exposure. We 380 propose that congestion information should be made visible at the IP 381 layer, so that any network node can measure the contribution to 382 congestion of an aggregate of traffic as easily as straight volume 383 can be measured today. Once the information is exposed in this way, 384 it is then possible to use it to measure the true impact of any 385 traffic on the network. 387 In general, congestion exposure gives operators a principled way to 388 hold their customers accountable for the impact on others of their 389 network usage and reward them for choosing congestion-sensitive 390 applications. 392 4.1. ECN - a Step in the Right Direction 394 Explicit Congestion Notification [RFC3168] allows routers to 395 explicitly tell end-hosts that they are approaching the point of 396 congestion. ECN builds on Active Queue Mechanisms such as random 397 early discard (RED) [RFC2309] by allowing the router to mark a packet 398 with a Congestion Experienced (CE) codepoint, rather than dropping 399 it. The probability of a packet being marked increases with the 400 length of the queue and thus the rate of CE marks is a guide to the 401 level of congestion at that queue. This CE codepoint travels forward 402 through the network to the receiver which then informs the sender 403 that it has seen congestion. The sender is then required to respond 404 as if it had experienced a packet loss. Because the CE codepoint is 405 visible in the IP layer, this approach reveals the upstream 406 congestion level for a packet. 408 Alas, this is not enough - ECN gives downstream nodes an idea of the 409 congestion so far for any flow. This can help hold a receiver 410 accountable for the congestion caused by incoming traffic. But a 411 receiver can only indirectly influence incoming congestion, by 412 politely asking the sender to control it. A receiver cannot make a 413 sender install an adaptive codec, or install LEDBAT instead of TCP 414 congestion-control. And a receiver cannot cause an attacker to stop 415 flooding it with traffic. 417 What is needed is knowledge of the downstream congestion level, for 418 which you need additional information that is still concealed from 419 the network. 421 5. ConEx Use Cases 423 This section sets out some of the use cases for ConEx. These use 424 cases rely on some of the conceptual elements described in 425 [ConEx-Abstract-Mech]. The authors don't claim this is an exhaustive 426 list of use cases, nor that these have equal merit. In most cases 427 ConEx is not the only solution to achieve these. But these use cases 428 represent a consensus among people that have been working on this 429 approach for some years. 431 5.1. ConEx as a basis for traffic management 433 Currently many operators impose some form of traffic management at 434 peak hours. This is a simple economic necessity -- the only reason 435 the Internet works as a commercial concern is that operators are able 436 to rely on statistical multiplexing to share their expensive core 437 network between large numbers of customers. In order to ensure all 438 customers get some chance to access the network, the "heaviest" 439 customers will be subjected to some form of traffic management at 440 peak times (typically a rate cap for certain types of traffic) 441 [Fair-use]. Often this traffic management is done with expensive 442 flow aware devices such as DPI boxes or flow-aware routers. 444 ConEx offers a better approach that will actually target the users 445 that are causing the congestion. By using Ingress or Egress 446 Policers, an ISP can identify which users are causing the greatest 447 Congestion Volume throughout the network. This can then be used as 448 the basis for traffic management decisions. The Ingress Policer 449 described in [Policing-freedom] is one interesting approach that 450 gives the user a congestion volume limit. So long as they stay 451 within their limit then their traffic is unaffected. Once they 452 exceed that limit then their traffic will be blocked temporarily. 454 5.2. ConEx to incentivise scavenger transports 456 Recent work proposes a new approach for QoS where traffic is provided 457 with a less than best effort or "scavenger" quality of service. The 458 idea is that low priority but high volume traffic such as OS updates, 459 P2P file transfers and view-later TV programs should be allowed to 460 use any spare network capacity, but should rapidly get out of the way 461 if a higher priority or interactive application starts up. One 462 solution being actively explored is LEDBAT which proposes a new 463 congestion control algorithm that is less aggressive in seeking out 464 bandwidth than TCP. 466 At present most operators assume a strong correlation between the 467 volume of a flow and the impact that flow causes in the network. 468 This assumption has been eroded by the growth of interactive 469 streaming which behaves in an inelastic manner and hence can cause 470 high congestion at relatively low data volumes. Currently LEDBAT- 471 like transports get no incentive from the ISP since they still 472 transfer large volumes of data and may reach high transfer speeds if 473 the network is uncongested. Consequently the only current incentive 474 for LEDBAT is that it can reduce self-congestion effects. 476 If the ISP has deployed a ConEx-aware Ingress Policer then they are 477 able to incentivise the use of LEDBAT because a user will be policed 478 according to the overall congestion volume their traffic generates, 479 not the rate or data volume. If all background file transfers are 480 only generating a low level of congestion, then the sender has more 481 "congestion budget" to "spend" on their interactive applications. It 482 can be shown [Kelly] that this approach improves social welfare -- in 483 other words if you limit the congestion that all users can generate 484 then everyone benefits from a better service. 486 5.3. Accounting for Congestion Volume 488 Accountability was one of the original design goals for the Internet 489 [Design-Philosophy]. At the time it was ranked low because the 490 network was non-commercial and it was assumed users had the best 491 interests of the network at heart. Nowadays users generally treat 492 the network as a commodity and the Internet has become highly 493 commercialised. This causes problems for operators and others which 494 they have tried to solve and often leads to a tragedy of the commons 495 where users end up fighting each other for scarce peak capacity. 497 The most elegant solution would be to introduce an Internet-wide 498 system of accountability where every actor in the network is held to 499 account for the impact they have on others. If Policers are placed 500 at every Network Ingress or Egress and Border Monitors at every 501 border, then you have the basis for a system of congestion 502 accounting. Simply by controlling the overall Congestion Volume each 503 end-system or stub-network can send you ensure everyone gets a better 504 service. 506 5.4. ConEx as a form of differential QoS 508 Most QoS approaches require the active participation of routers to 509 control the delay and loss characteristics for the traffic. For 510 real-time interactive traffic it is clear that low delay (and 511 predictable jitter) are critical, and thus these probably always need 512 different treatment at a router. However if low loss is the issue 513 then ConEx offers an alternative approach. 515 Assuming the ingress ISP has deployed a ConEx Ingress Policer, then 516 the only control on a user's traffic is dependent on the congestion 517 that user has caused. Likewise, if they are receiving traffic 518 through a ConEx Egress Policer then their ISP will impose traffic 519 controls (prioritisation, rate limiting, etc) based on the congestion 520 they have caused. If an end-user (be they the receiver or sender) 521 wants to prioritise some traffic over other traffic then they can 522 allow that traffic to generate or cause more congestion. The price 523 they will pay will be to reduce the congestion that their other 524 traffic causes. 526 Streaming video content-delivery is a good candidate for such ConEx- 527 mediated QoS. Such traffic can tolerate moderately high delays, but 528 there are strong economic pressures to maintain a high enough data 529 rate (as that will directly influence the Quality of Experience the 530 end-user receives. This approach removes the need for bandwidth 531 brokers to establish QoS sessions, by removing the need to coordinate 532 requests from multiple sources to pre-allocate bandwidth, as well as 533 to coordinate which allocations to revoke when bandwidth predictions 534 turn out to be wrong. There is also no need to "rate-police" at the 535 boundaries on a per-flow basis, removing the need to keep per-flow 536 state (which in turn makes this approach more scalable). 538 5.5. Partial vs. Full Deployment 540 In a fully-deployed ConEx-enabled internet, [QoS-Models] shows that 541 ISP settlements based on congestion volume can allocate money to 542 where upgrades are needed. Fully-deployed implies that ConEx-marked 543 packets which have not exhausted their expected congestion would go 544 through a congested path in preference to non-ConEx packets, with 545 money changing hands to justify that priority. 547 In a partial deployment, routers that ignore ConEx markings and let 548 them pass unaltered are no problem unless they become congested and 549 drop packets. Since ConEx incentivises the use of lower congestion 550 transports, such congestion drops should anyway become rare events. 551 ConEx-unaware routers that do drop ConEx-marked packets would cause a 552 problem so to minimise this risk ConEx should be designed such that 553 ConEx packets will appear valid to any node they traverse. Failing 554 that it could be possible to bypass such nodes with a tunnel. 556 If any network is not ConEx enabled then the sender and receiver have 557 to rely on ECN-marking or packet drops to establish the congestion 558 level. If the receiver isn't ConEx-enabled then there needs to be 559 some form of compatibility mode. Even in such partial deployments 560 the end-users and access networks will benefit from ConEx. This will 561 put create incentives for ConEx to be more widely adopted as access 562 networks put pressure on their backhaul providers to use congestion 563 as the basis of their interconnect agreement. 565 The actual charge per unit of congestion would be specified in an 566 interconnection agreement, with economic pressure driving that charge 567 downward to the cost to upgrade whenever alternative paths are 568 available. That charge would most likely be invisible to the 569 majority of users. Instead such users will have a contractual 570 allowance to cause congestion, and would see packets dropped when 571 that allowance is depleted. 573 Once an Autonomous System (AS) agrees to pay any congestion charges 574 to any other AS it forwards to, it has an economic incentive to 575 increase congestion-so-far marking for any congestion within its 576 network. Failure to do this quickly becomes a significant cost, 577 giving it an incentive to turn on such marking. 579 End users (or the writers of the applications they use) will be given 580 an incentive to use a congestion control that back off more 581 aggressively than TCP for any elastic traffic. Indeed they will 582 actually have an incentive to use fully weighted congestion controls 583 that allow traffic to cause congestion in proportion to its priority. 584 Traffic which backs off more aggressively than TCP will see 585 congestion charges remain the same (or even drop) as congestion 586 increases; traffic which backs off less aggressively will see charges 587 rise, but the user may be prepared to accept this if it is high- 588 priority traffic; traffic which backs off not at all will see charges 589 rise dramatically. 591 6. Other issues 593 6.1. Congestion as a Commercial Secret 595 Network operators have long viewed the congestion levels in their 596 network as a business secret. In some ways this harks back to the 597 days of fixed-line telecommunications where congestion manifested as 598 failed connections or dropped calls. But even in modern data-centric 599 packet networks congestion is viewed as a secret not to be shared 600 with competitors. It can be debated whether this view is sensible, 601 but it may make operators uneasy about deploying ConEx. The 602 following two examples highlight some of the arguments used: 604 o An ISP buys backhaul capacity from an operator. Most operators 605 want their customers to get a decent service and so they want the 606 backhaul to be relatively uncongested. If there is competition, 607 operators will seek to reassure their customers (the operators) 608 that their network is not congested in order to attract their 609 custom. Some operators may see ConEx as a threat since it will 610 enable those operators to see the actual congestion in their 611 network. On the other hand, operators with low congestion could 612 use ConEx to show how well their network performs, and so might 613 have an incentive to enable it. 615 o Operators would like to be part of the lucrative content provision 616 market. Currently the ISP can gain a competitive edge as it can 617 put its own content in a higher QoS class, whereas traffic from 618 content providers has to use the Best Effort class. The ISP may 619 take the view that if they can conceal the congestion level in 620 their Best Effort class this will make it harder for the content 621 provider to maintain a good level of QoS. But in reality the 622 Content Provider will just use the feedback mechanisms in 623 streaming protocols such as Adobe Flash to monitor the congestion. 625 Of course some might say that the idea of keeping congestion secret 626 is silly. After all, end-hosts already have knowledge of the 627 congestion throughout the network, albeit only along specific paths, 628 and operators can work out that there is persistent congestion as 629 their customers will be suffering degraded network performance. 631 6.2. Information Security 633 make a source believe it has seen more congestion than it has 635 hijack a user's identity and make it appear they are dishonest at an 636 egress policer 638 clear or otherwise tamper with the ConEx markings 640 ... 642 {ToDo} Write these up properly... 644 7. Security Considerations 646 This document proposes a mechanism tagging onto Explicit Congestion 647 Notification [RFC3168], and inherits the security issues listed 648 therein. The additional issues from ConEx markings relate to the 649 degree of trust each forwarding point places in the ConEx markings it 650 receives, which is a business decision mostly orthogonal to the 651 markings themselves. 653 One expected use of exposed congestion information is to hold the 654 end-to-end transport and the network accountable to each other. The 655 network cannot be relied on to report information to the receiver 656 against its interest, and the same applies for the information the 657 receiver feeds back to the sender, and that the sender reports back 658 to the network. Looking at each in turn: 660 The Network In general it is not in any network's interest to under- 661 declare congestion since this will have potentially negative 662 consequences for all users of that network. It may be in its 663 interest to over-declare congestion if, for instance, it wishes to 664 force traffic to move away to a different network or simply to 665 reduce the amount of traffic it is carrying. Congestion Exposure 666 itself won't significantly alter the incentives for and against 667 honest declaration of congestion by a network, but we can imagine 668 applications of Congestion Exposure that will change these 669 incentives. There is a perception among network operators that 670 their level of congestion is a business secret. Today, congestion 671 is one of the worst-kept secrets a network has, because end-hosts 672 can see congestion better than network operators can. Congestion 673 Exposure will enable network operators to pinpoint whether 674 congestion is on one side or the other of any border. It is 675 conceivable that forwarders with underprovisioned networks may try 676 to obstruct deployment of Congestion Exposure. 678 The Receiver Receivers generally have an incentive to under-declare 679 congestion since they generally wish to receive the data from the 680 sender as rapidly as possible. [Savage] explains how a receiver 681 can significantly improve their throughput my failing to declare 682 congestion. This is a problem with or without Congestion 683 Exposure. [KGao] explains one possible technique to encourage 684 receiver's to be honest in their declaration of congestion. 686 The Sender One proposed mechanism for Congestion Exposure deployment 687 adds a requirement for a sender to advise the network how much 688 congestion it has suffered or caused. Although most senders 689 currently respond to congestion they are informed of, one use of 690 exposed congestion information might be to encourage sources of 691 persistent congestion to back off more aggressively. Then clearly 692 there may be an incentive for the sender to under-declare 693 congestion. This will be a particular problem with sources of 694 flooding attacks. "Policing" mechanisms have been proposed to 695 deal with this. 697 In addition there are potential problems from source spoofing. A 698 malicious sender can pretend to be another user by spoofing the 699 source address. Congestion Exposure allows for "Policers" and 700 "Traffic Shapers" so as to be robust against injection of false 701 congestion information into the forward path. 703 8. IANA Considerations 705 This document does not require actions by IANA. 707 9. Acknowledgments 709 Bob Briscoe is partly funded by Trilogy, a research project (ICT- 710 216372) supported by the European Community under its Seventh 711 Framework Programme. The views expressed here are those of the 712 author only. 714 The authors would like to thank Contributing Authors Bernard Aboba, 715 Joao Taveira Araujo, Louise Burness, Alissa Cooper, Philip Eardley, 716 Michael Menth, and Hannes Tschofenig for their inputs to this 717 document. Useful feedback was also provided by Dirk Kutscher. 719 10. References 721 10.1. Normative References 723 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, 724 "The Addition of Explicit Congestion 725 Notification (ECN) to IP", RFC 3168, 726 September 2001. 728 10.2. Informative References 730 [BB-incentive] MIT Communications Futures Program (CFP) and 731 Cambridge University Communications Research 732 Network, "The Broadband Incentive Problem", 733 September 2005. 735 [ConEx-Abstract-Mech] Briscoe, B., "Congestion Exposure (ConEx) 736 Concepts and Abstract Mechanism", 737 draft-mathis-conex-abstract-mech-00 (work in 738 progress), October 2010. 740 [Design-Philosophy] Clarke, D., "The Design Philosophy of the 741 DARPA Internet Protocols", 1988. 743 [Fair-use] Broadband Choices, "Truth about 'fair usage' 744 broadband", 2009. 746 [Fairer-faster] Briscoe, B., "A Fairer Faster Internet 747 Protocol", IEEE Spectrum Dec 2008 pp38-43, 748 December 2008. 750 [KGao] Gao, K. and C. Wang, "Incrementally Deployable 751 Prevention to TCP Attack with Misbehaving 752 Receivers", December 2004. 754 [Kelly] Kelly, F., Maulloo, A., and D. Tan, "Rate 755 control for communication networks: shadow 756 prices, proportional fairness and stability", 757 Journal of the Operational Research 758 Society 49(3) 237--252, 1998, . 761 [LEDBAT] Shalunov, S., "Low Extra Delay Background 762 Transport (LEDBAT)", 763 draft-ietf-ledbat-congestion-01 (work in 764 progress), March 2010. 766 [Malice] Briscoe, B., "Using Self Interest to Prevent 767 Malice; Fixing the Denial of Service Flaw of 768 the Internet", WESII - Workshop on the 769 Economics of Securing the Information 770 Infrastructure 2006, 2006, . 773 [OfCom] Ofcom: Office of Communications, "UK Broadband 774 Speeds 2008: Research report", January 2009. 776 [Padhye] Padhye, J., Firoiu, V., Towsley, D., and J. 777 Kurose, "Modeling TCP Throughput: A Simple 778 Model and its Empirical Validation", ACM 779 SIGCOMM Computer Communications Review Vol 780 28(4), pages 303-314, May 1998. 782 [Policing-freedom] Briscoe, B., Jacquet, A., and T. Moncaster, 783 "Policing Freedom to Use the Internet Resource 784 Pool", RE-Arch 2008 hosted at the 2008 CoNEXT 785 conference , December 2008. 787 [QoS-Models] Briscoe, B. and S. Rudkin, "Commercial Models 788 for IP Quality of Service Interconnect", BTTJ 789 Special Edition on IP Quality of Service vol 790 23 (2), April 2005. 792 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, 793 B., Deering, S., Estrin, D., Floyd, S., 794 Jacobson, V., Minshall, G., Partridge, C., 795 Peterson, L., Ramakrishnan, K., Shenker, S., 796 Wroclawski, J., and L. Zhang, "Recommendations 797 on Queue Management and Congestion Avoidance 798 in the Internet", RFC 2309, April 1998. 800 [Re-Feedback] Briscoe, B., Jacquet, A., Di Cairano- 801 Gilfedder, C., Salvatori, A., Soppera, A., and 802 M. Koyabe, "Policing Congestion Response in an 803 Internetwork Using Re-Feedback", ACM SIGCOMM 804 CCR 35(4)277--288, August 2005, . 808 [Savage] Savage, S., Wetherall, D., and T. Anderson, 809 "TCP Congestion Control with a Misbehaving 810 Receiver", ACM SIGCOMM Computer Communication 811 Review , 1999. 813 [re-ecn-motive] Briscoe, B., Jacquet, A., Moncaster, T., and 814 A. Smith, "Re-ECN: A Framework for adding 815 Congestion Accountability to TCP/IP", 816 draft-briscoe-tsvwg-re-ecn-tcp-motivation-02 817 (work in progress), October 2010. 819 Authors' Addresses 821 Bob Briscoe 822 BT 823 B54/77, Adastral Park 824 Martlesham Heath 825 Ipswich IP5 3RE 826 UK 828 Phone: +44 1473 645196 829 EMail: bob.briscoe@bt.com 830 URI: http://bobbriscoe.net/ 832 Richard Woundy 833 Comcast 834 Comcast Cable Communications 835 27 Industrial Avenue 836 Chelmsford, MA 01824 837 US 839 EMail: richard_woundy@cable.comcast.com 840 URI: http://www.comcast.com 841 Toby Moncaster (editor) 842 Moncaster.com 843 Dukes 844 Layer Marney 845 Colchester CO5 9UZ 846 UK 848 EMail: toby@moncaster.com 850 John Leslie (editor) 851 JLC.net 852 10 Souhegan Street 853 Milford, NH 03055 854 US 856 EMail: john@jlc.net