idnits 2.17.1 draft-ietf-conex-concepts-uses-04.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 (March 2, 2012) is 4409 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-briscoe-conex-initial-deploy - is the name correct? == Outdated reference: A later version (-13) exists of draft-ietf-conex-abstract-mech-03 == Outdated reference: A later version (-10) exists of draft-ietf-ledbat-congestion-09 -- No information found for draft-kuehlewind-conex-accurate-ecn - is the name correct? -- No information found for draft-kuehlewind-conex-tcp-modifications - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ConEx B. Briscoe, Ed. 3 Internet-Draft BT 4 Intended status: Informational R. Woundy, Ed. 5 Expires: September 3, 2012 Comcast 6 A. Cooper, Ed. 7 CDT 8 March 2, 2012 10 ConEx Concepts and Use Cases 11 draft-ietf-conex-concepts-uses-04 13 Abstract 15 This document provides the entry point to the set of documentation 16 about the Congestion Exposure (ConEx) protocol. It explains the 17 motivation for including a ConEx marking at the IP layer: to expose 18 information about congestion to network nodes. Although such 19 information may have a number of uses, this document focuses on how 20 the information communicated by the ConEx marking can serve as the 21 basis for significantly more efficient and effective traffic 22 management than what exists on the Internet today. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 3, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Congestion . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Congestion-Volume . . . . . . . . . . . . . . . . . . . . 5 62 2.3. Rest-of-Path Congestion . . . . . . . . . . . . . . . . . 5 63 2.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Core Use Case: Informing Traffic Management . . . . . . . . . 7 65 3.1. Use Case Description . . . . . . . . . . . . . . . . . . . 7 66 3.2. Additional Benefits . . . . . . . . . . . . . . . . . . . 8 67 3.3. Comparison with Existing Approaches . . . . . . . . . . . 9 68 4. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 10 69 5. Deployment Arrangements . . . . . . . . . . . . . . . . . . . 11 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 73 8.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 13 74 9. Informative References . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 The power of Internet technology comes from multiplexing shared 79 capacity with packets rather than circuits. Network operators aim to 80 provide sufficient shared capacity, but when too much packet load 81 meets too little shared capacity, congestion results. Congestion 82 appears as either increased delay, dropped packets or packets 83 explicitly marked with Explicit Congestion Notification (ECN) 84 markings [RFC3168]. As described in Figure 1, congestion control 85 currently relies on the transport receiver detecting these 86 'Congestion Signals' and informing the transport sender in 87 'Congestion Feedback Signals.' The sender is then expected to reduce 88 its rate in response. 90 This document provides the entry point to the set of documentation 91 about the Congestion Exposure (ConEx) protocol. It focuses on the 92 motivation for including a ConEx marking at the IP layer. (A 93 companion document, [I-D.ietf-conex-abstract-mech], focuses on the 94 mechanics of the protocol.) Briefly, the idea is for the sender to 95 continually signal expected congestion in the headers of any data it 96 sends. To a first approximation, the sender does this by relaying 97 the 'Congestion Feedback Signals' back into the IP layer. They then 98 travel unchanged across the network to the receiver (shown as 'IP- 99 Layer-ConEx-Signals' in Figure 1). This enables IP layer devices on 100 the path to see information about the whole path congestion. 102 ,---------. ,---------. 103 |Transport| |Transport| 104 | Sender | . |Receiver | 105 | | /|___________________________________________| | 106 | ,-<---------------Congestion-Feedback-Signals--<--------. | 107 | | |/ | | | 108 | | |\ Transport Layer Feedback Flow | | | 109 | | | \ ___________________________________________| | | 110 | | | \| | | | 111 | | | ' ,-----------. . | | | 112 | | |_____________| |_______________|\ | | | 113 | | | IP Layer | | Data Flow \ | | | 114 | | | |(Congested)| \ | | | 115 | | | | Network |--Congestion-Signals--->-' | 116 | | | | Device | \| | 117 | | | | | /| | 118 | `----------->--(new)-IP-Layer-ConEx-Signals-------->| | 119 | | | | / | | 120 | |_____________| |_______________ / | | 121 | | | | |/ | | 122 `---------' `-----------' ' `---------' 123 Figure 1: The ConEx Protocol in the Internet Architecture 125 One of the key benefits of exposing this congestion information at 126 the IP layer is that it makes the information available to network 127 operators for use as input into their traffic management procedures. 128 As shown in Figure 1, a ConEx-enabled sender signals whole path 129 congestion, which is (approximately) the congestion one round trip 130 time earlier as reported by the receiver to the sender. The ConEx 131 signal is a mark in the IP header that is easy for any IP device to 132 read. Therefore a node performing traffic management can count 133 congestion as easily as it might count data volume today by simply 134 counting the volume of packets with ConEx markings. 136 ConEx-based traffic management can make highly efficient use of 137 capacity. In times of no congestion, all traffic management 138 restraints can be removed, leaving the network's full capacity 139 available to all its users. If some users on the network cause 140 disproportionate congestion, the traffic management function can 141 learn about this and directly limit those users' traffic in order to 142 protect the service of other users sharing the same capacity. ConEx- 143 based traffic management thus presents a step change in terms of the 144 options available to network operators for managing traffic on their 145 networks. 147 The remainder of this document explains the concepts behind ConEx and 148 how exposing congestion can significantly improve Internet traffic 149 management, among other benefits. Section 2 introduces a number of 150 concepts that are fundamental to understanding how ConEx-based 151 traffic management works. Section 3 shows how ConEx can be used for 152 traffic management, discusses additional benefits from such usage, 153 and compares ConEx-based traffic management to existing traffic 154 management approaches. Section 4 discusses other related use cases. 155 Section 5 briefly discusses deployment arrangements. The final 156 sections are standard RFC back matter. 158 2. Concepts 160 ConEx relies on a precise definition of congestion and a number of 161 newer concepts that are introduced and defined in this section. 163 2.1. Congestion 165 Despite its central role in network control and management, 166 congestion is a remarkably difficult concept to define. Experts in 167 different disciplines and with different perspectives define 168 congestion in a variety of ways [Bauer09]. 170 The definition used for the purposes of ConEx is expressed as the 171 probability of packet loss (or the probability of packet marking if 172 ECN is in use). This definition focuses on how congestion is 173 measured, rather than describing congestion as a condition or state. 175 2.2. Congestion-Volume 177 The metric that ConEx exposes is congestion-volume: the volume of 178 bytes dropped or ECN-marked in a given period of time. Counting 179 congestion-volume allows each user to be held responsible for his or 180 her contribution to causing congestion. Congestion-volume is a 181 property of traffic, whereas congestion describes a link or a path. 183 To understand congestion-volume, consider a simple example. Imagine 184 Alice sends 1GB while the loss-probability is a constant 0.2%. Her 185 contribution to congestion -- her congestion-volume -- is 1GB x 0.2% 186 = 2MB. If she then sends 3GB while the loss-probability is 0.1%, 187 this adds 3MB to her congestion-volume. Her total contribution to 188 congestion is then 2MB+3MB = 5MB. 190 Fortunately, measuring Alice's congestion-volume on a real network 191 does not require the kind of arithmetic shown above because 192 congestion-volume can be directly measured by counting the total 193 volume of Alice's traffic that gets discarded or ECN-marked. (A 194 queue with a percentage loss involves multiplication inherently.) 196 2.3. Rest-of-Path Congestion 198 At a particular measurement point within a network, "rest-of-path 199 congestion" (also known as "downstream congestion") is the level of 200 congestion that a traffic flow is expected to experience between the 201 measurement point and its final destination. "Upstream congestion" 202 is the congestion experienced up to the measurement point. 204 Measurement points that only observe ECN marks are capable of 205 measuring upstream congestion, whereas measurement points that 206 observe ConEx marks in addition to ECN marks can use both kinds of 207 marks to calculate rest-of-path congestion. When ECN signals are 208 monitored in the middle of a network, they indicate the congestion 209 experienced so far on the path (upstream congestion). In contrast, 210 the ConEx signals inserted into IP headers as shown in Figure 1 211 indicate the congestion along a whole path from source to 212 destination. Therefore if a measurement point detects both of these 213 signals, it can subtract the level of ECN (upstream congestion) from 214 the level of ConEx (whole path) to derive a measure of the congestion 215 that packets are likely to experience between the monitoring point 216 and their destination (rest-of-path congestion). 218 [I-D.ietf-conex-abstract-mech] has further discussion of the 219 constraints around the network's ability to measure rest-of-path 220 congestion. 222 2.4. Definitions 224 Congestion: In general, congestion occurs when any user's traffic 225 suffers loss, ECN marking, or increased delay as a result of one 226 or more network resources becoming overloaded. For the purposes 227 of ConEx, congestion is measured using the concrete signals 228 provided by loss and ECN markings (delay is not considered). 229 Congestion is measured as the probability of loss or the 230 probability of ECN marking, usually expressed as a dimensionless 231 percentage. 233 Congestion-volume: For any granularity of traffic (packet, flow, 234 aggregate, link, etc.), the volume of bytes dropped or ECN-marked 235 in a given period of time. Conceptually, data volume multiplied 236 by the congestion each packet of the volume experienced. Usually 237 expressed in bytes (or MB or GB). 239 Congestion policer: A logical entity that allows a network operator 240 to monitor each user's congestion-volume and enforce congestion- 241 volume limits (discussed in Section 3.1). 243 Rest-of-path congestion (or downstream congestion): The congestion a 244 flow of traffic is expected to experience on the remainder of its 245 path. In other words, at a measurement point in the network the 246 rest-of-path congestion is the congestion the traffic flow has yet 247 to experience as it travels from that point to the receiver. 249 Upstream congestion: The accumulated congestion experienced by a 250 traffic flow thus far, relative to a point along its path. In 251 other words, at a measurement point in the network the upstream 252 congestion is the accumulated congestion the traffic flow has 253 experienced as it travels from the sender to that point. At the 254 receiver this is equivalent to the end-to-end congestion level 255 that (usually) is reported back to the sender. 257 Network operators (or providers): Operator of a residential, 258 commercial, enterprise, campus or other network. 260 User: The contractual entity that represents an individual, 261 household, business, or institution that uses the service of a 262 network operator. There is no implication that the contract has 263 to be commercial; for instance, the users of a university or 264 enterprise network service could be students or employees who do 265 not pay for access but may be required to comply with some form of 266 contract or acceptable use policy. There is also no implication 267 that every user is an end user. Where two networks form a 268 customer-provider relationship, the term user applies to the 269 customer network. 271 [I-D.ietf-conex-abstract-mech] gives further definitions for aspects 272 of ConEx related to protocol mechanisms. 274 3. Core Use Case: Informing Traffic Management 276 This section explains how ConEx could be used as the basis for 277 traffic management, highlights additional benefits derived from 278 having ConEx-aware nodes on the network, and compares ConEx-based 279 traffic management to existing approaches. 281 3.1. Use Case Description 283 One of the key benefits that ConEx can deliver is in helping network 284 operators to improve how they manage traffic on their networks. 285 Consider the common case of a commercial broadband network where a 286 relatively small number of users place disproportionate demand on 287 network resources, at times resulting in congestion. The network 288 operator seeks a way to manage traffic such that the traffic that 289 contributes more to congestion bears more of the brunt of the 290 management. 292 Assuming ConEx signals are visible at the IP layer, the network 293 operator can accomplish this by placing a congestion policer at an 294 enforcement point within the network and configuring it with a 295 traffic management policy that monitors each user's contribution to 296 congestion. As described in [I-D.ietf-conex-abstract-mech] and 297 elaborated in [CongPol], one way to implement a congestion policer is 298 in a similar way to a bit-rate policer, except that it monitors and 299 polices congestion-volume rather than bit-rate. When implemented as 300 a token bucket, the tokens provide users with the right to cause bits 301 of congestion-volume, rather than to send bits of data volume. The 302 fill rate represents each user's congestion-volume quota. 304 The congestion policer monitors the ConEx signals of the traffic 305 entering the network. As long as the network remains uncongested and 306 users stay within their quotas, no action is taken. When the network 307 becomes congested and a user exhausts his quota, some action is taken 308 against the traffic that breached the quota in accordance with the 309 network operator's traffic management policy. For example, the 310 traffic may be dropped, delayed, or marked with a lower QoS class. 311 In this way, traffic is managed according to its contribution to 312 congestion -- not some application- or flow-specific policy -- and is 313 not managed at all during times of no congestion. 315 As an example of how a network operator might employ a ConEx-based 316 traffic management system, consider a typical DSL network 317 architecture (as elaborated in [TR-059] and [TR-101]). Traffic is 318 routed from regional and global IP networks to an operator-controlled 319 IP node, the Broadband Remote Access Server (BRAS). From the BRAS, 320 traffic is delivered to access nodes. The BRAS carries enhanced 321 functionality including IP QoS and traffic management capabilities. 323 Based on typical network designs and current traffic patterns, the 324 BRAS is located at a point in the network where congestion may be 325 most likely to occur. As a consequence, the BRAS is a logical choice 326 of location for deploying traffic management functionality. By 327 deploying a congestion policer at the BRAS location, the network 328 operator can measure the congestion-volume created by users within 329 the access nodes and police misbehaving users before their traffic 330 affects others on the access network. The policer would be 331 provisioned with a traffic management policy, perhaps directing the 332 BRAS to drop packets from users that exceed their congestion-volume 333 quotas during times of congestion. Those users would be likely to 334 react in the typical way to drops, backing off (assuming use of 335 standard TCP), and thereby lowering their congestion-volumes back 336 within the quota limits. 338 3.2. Additional Benefits 340 The ConEx-based approach to traffic management has a number of 341 benefits in addition to efficient management of traffic. It provides 342 incentives for users to make use of scavenger transport protocols, 343 such as [I-D.ietf-ledbat-congestion], that provide ways for bulk- 344 transfer applications to rapidly yield when interactive applications 345 require capacity. With a congestion policer in place as described in 346 Section 3.1, users of these protocols will be less likely to run 347 afoul of the network operator's traffic management policy than those 348 whose bulk-transfer applications generate the same volume of traffic 349 without being sensitive to congestion. 351 ConEx-based traffic management also makes it possible for a user to 352 control the relative performance among its own traffic flows. If a 353 user wants some flows to have more bandwidth than others, it can 354 allow the higher bandwidth traffic to generate more congestion 355 signals, leaving less congestion "budget" for the user to "spend" on 356 other traffic. This approach is most relevant if congestion is 357 signalled by ECN, because no impairment due to loss is involved and 358 delay can remain low. 360 3.3. Comparison with Existing Approaches 362 A variety of approaches already exist for network operators to manage 363 congestion, traffic, and the disproportionate usage of scarce 364 capacity by a small number of users. Common approaches can be 365 categorized as rate-based, volume-based, or application-based. 367 Rate-based approaches constrain the traffic rate per user or per 368 network. A user's peak and average (or "committed") rate may be 369 limited. These approaches have the potential to either over- or 370 under-constrain the network, suppressing rates even when the network 371 is uncongested or not suppressing them enough during heavy usage 372 periods. 374 Round-robin scheduling and fair queuing were developed to address 375 these problems. They equalize relative rates between active users 376 (or flows) at a known bottleneck. The bit-rate allocated to any one 377 user depends on the number of active users at each instant. The 378 drawback of these approaches is that they favor heavy users over 379 light users over time, because they do not have any memory of usage. 380 Heavy users will be active at every instant whereas light users will 381 only occupy their share of the link occassionally, but bit-rate is 382 shared instant by instant. 384 Volume-based approaches measure the overall volume of traffic a user 385 sends (and/or receives) over time. Users may be subject to an 386 absolute volume cap (for example, 10GB per month) or the "heaviest" 387 users may be sanctioned in some other manner. Many providers use 388 monthly volume limits and count volume regardless of whether the 389 network is congested or not, creating the potential for over- or 390 under-constraining problems, as with the original rate-based 391 approaches. 393 ConEx-based approaches, by comparison, only react during times of 394 congestion and in proportion to each user's congestion contribution, 395 making more efficient use of capacity and more proportionate 396 management decisions. 398 Unlike ConEx-based approaches, neither rate-based nor volume-based 399 approaches provide incentives for applications to use scavenger 400 transports. They may even penalize users of applications that employ 401 scavenger services for the large amount of volume they send, rather 402 than rewarding them for carefully avoiding congestion while sending 403 it. While the volume-based approach described in Comcast's Protocol- 404 Agnostic Congestion Management System [RFC6057] aims to overcome the 405 over/under-constraining problem by only measuring volume and 406 triggering traffic management action during periods of high 407 utilization, it still does not provide incentives to use scavenger 408 transports because congestion-causing volume cannot be distinguished 409 from volume overall. ConEx provides this ability. 411 Application-based approaches use deep packet inspection or other 412 techniques to determine what application a given traffic flow is 413 associated with. Network operators may then use this information to 414 rate-limit or otherwise sanction certain applications, in some cases 415 only during peak hours. These approaches suffer from being at odds 416 with IPSec and some application-layer encryption, and they may raise 417 additional policy concerns. In contrast, ConEx offers an 418 application-agnostic metric to serve as the basis for traffic 419 management decisions. 421 The existing types of approaches share a further limitation that 422 ConEx can help to overcome: performance uncertainty. Flat-rate 423 pricing plans are popular because users appreciate the certainty of 424 having their monthly bill amount remain the same for each billing 425 period, allowing them to plan their costs accordingly. But while 426 flat-rate pricing avoids billing uncertainty, it creates performance 427 uncertainty: users cannot know whether the performance of their 428 connections is being altered or degraded based on how the network 429 operator is attempting to manage congestion. By exposing congestion 430 information at the IP layer, ConEx instead provides a metric that can 431 serve as an open, transparent basis for traffic management policies 432 that both providers and their customers can measure and verify. It 433 can be used to reduce the performance uncertainty that some users 434 currently experience. 436 4. Other Use Cases 438 ConEx information can be put to a number of uses other than informing 439 traffic management. These include: 441 Informing inter-operator contracts: ConEx information is made 442 visible to every IP node, including border nodes between networks. 443 Network operators can use this information to measure how much 444 traffic from each network contributes to congestion in the other. 445 As such, congestion-volume could be included as a metric in inter- 446 operator contracts, just as volume or bit-rate are included today. 448 Enabling more efficient capacity provisioning: Section 3.2 explained 449 how operators can use ConEx-based traffic management to encourage 450 use of scavenger transports, which significantly improves the 451 performance of interactive applications while still allowing heavy 452 users to transfer high volumes. Here we explain how this can also 453 benefit network operators. 455 Today, when loss, delay or averaged utilization exceeds a certain 456 threshold, some operators just buy more capacity without 457 attempting to manage the traffic. Other operators prefer to limit 458 a minority of heavy users at peak times, but they still eventually 459 buy more capacity when utilization rises. 461 With ConEx-based traffic management, a network operator should be 462 able to provision capacity more efficiently. An operator could 463 benefit from this in a variety of ways. For example, the operator 464 could add capacity as it would do without ConEx, but deliver 465 better quality of service for its users. Or the operator could 466 delay adding capacity while delivering similar quality of service 467 to what it currently provides. 469 5. Deployment Arrangements 471 ConEx is designed so that it can be incrementally deployed in the 472 Internet and still be valuable for early adopters. As long as some 473 senders are ConEx-enabled, a network on the path can unilaterally use 474 ConEx-aware policy devices for traffic management; no changes to 475 network forwarding elements are needed and ConEx still works if there 476 are other networks on the path that are unaware of ConEx marks. 478 The above two steps seem to represent a stand-off where neither step 479 is useful until the other has made the first move: i) some sending 480 hosts must be modifed to give information to the network and ii) a 481 network must deploy policy devices to monitor this information and 482 act on it. Nonetheless, the developer of a scavenger transport 483 protocol like LEDBAT does stand to benefit from deploying ConEx. In 484 this case the developer makes the first move, expecting it will 485 prompt at least some networks to move in response, using the ConEx 486 information to reward users of the scavenger protocol. 488 On the host side, we have already shown (Figure Figure 1) how the 489 sender piggy-backs ConEx signals on normal data packets to re-insert 490 feedback about packet drops (and/or ECN) back into the IP layer. In 491 the case of TCP, [I-D.kuehlewind-conex-tcp-modifications] proposes 492 the required sender modifications. ConEx works with any TCP receiver 493 as long as it uses SACK, which most do. There is a receiver 494 optimisation [I-D.kuehlewind-conex-accurate-ecn] that improves ConEx 495 precision when using ECN, but ConEx can still use ECN without it. 497 On the network side the provider solely needs to place ConEx 498 congestion policers at each ingress to its network, in a similar 499 arrangement to the edge-policed architecture of Diffserv [RFC2475]. 501 A sender can choose whether to send ConEx or Not-ConEx packets. 502 ConEx packets bring information to the policer about congestion 503 expected on the rest of the path beyond the policer. Not-ConEx 504 packets bring no such information. Therefore the network will tend 505 to rate-limit not-ConEx packets conservatively in order to manage the 506 unknown risk of congestion. In contrast, a network doesn't normally 507 need to rate-limit ConEx-enabled packets unless they reveal a 508 persistently high contribution to congestion. This natural tendency 509 for networks to favour senders that provide ConEx information 510 reinforces ConEx deployment. 512 The above gives only the most salient aspects of ConEx deployment. 513 For further detail, [I-D.ietf-conex-abstract-mech] describes the 514 incremental deployment features of the ConEx protocol and the 515 components that need to be deployed for ConEx to work. Then 516 [I-D.briscoe-conex-initial-deploy] gives concrete examples of 517 feasible initial deployment scenarios. 519 6. Security Considerations 521 This document does not specify a mechanism, it merely motivates 522 congestion exposure at the IP layer. Therefore security 523 considerations are described in the companion document that gives an 524 abstract description of the ConEx protocol and the components that 525 would use it [I-D.ietf-conex-abstract-mech]. 527 7. IANA Considerations 529 This document does not require actions by IANA. 531 8. Acknowledgments 533 Bob Briscoe was partly funded by Trilogy, a research project (ICT- 534 216372) supported by the European Community under its Seventh 535 Framework Programme. The views expressed here are those of the 536 author only. 538 The authors would like to thank the many people that have commented 539 on this document: Bernard Aboba, Mikael Abrahamsson, Joao Taveira 540 Araujo, Marcelo Bagnulo Braun, Steve Bauer, Caitlin Bestler, Steven 541 Blake, Louise Burness, Ken Carlberg, Nandita Dukkipati, Dave McDysan, 542 Wes Eddy, Matthew Ford, Ingemar Johansson, Georgios Karagiannis, 543 Mirja Kuehlewind, Dirk Kutscher, Zhu Lei, Kevin Mason, Matt Mathis, 544 Michael Menth, Chris Morrow, Tim Shepard, Hannes Tschofenig and 545 Stuart Venters. Please accept our apologies if your name has been 546 missed off this list. 548 8.1. Contributors 550 Philip Eardley and Andrea Soppera made helpful text contributions to 551 this document. 553 The following co-edited this document through most of its life: 555 Toby Moncaster 556 Computer Laboratory 557 William Gates Building 558 JJ Thomson Avenue 559 Cambridge, CB3 0FD 560 UK 561 EMail: toby.moncaster@cl.cam.ac.uk 563 John Leslie 564 JLC.net 565 10 Souhegan Street 566 Milford, NH 03055 567 US 568 EMail: john@jlc.net 570 9. Informative References 572 [Bauer09] Bauer, S., Clark, D., and 573 W. Lehr, "The Evolution of 574 Internet Congestion", 2009. 576 [CongPol] Briscoe, B., Jacquet, A., 577 and T. Moncaster, "Policing 578 Freedom to Use the Internet 579 Resource Pool", RE-Arch 580 2008 hosted at the 2008 581 CoNEXT conference , 582 December 2008. 584 [I-D.briscoe-conex-initial-deploy] Briscoe, B., "Initial 585 Congestion Exposure (ConEx) 586 Deployment Examples", draft 587 -briscoe-conex-initial- 588 deploy-01 (work in 589 progress), November 2011. 591 [I-D.ietf-conex-abstract-mech] Mathis, M. and B. Briscoe, 592 "Congestion Exposure 593 (ConEx) Concepts and 594 Abstract Mechanism", draft- 595 ietf-conex-abstract-mech-03 596 (work in progress), 597 October 2011. 599 [I-D.ietf-ledbat-congestion] Hazel, G., Iyengar, J., 600 Kuehlewind, M., and S. 601 Shalunov, "Low Extra Delay 602 Background Transport 603 (LEDBAT)", draft-ietf- 604 ledbat-congestion-09 (work 605 in progress), October 2011. 607 [I-D.kuehlewind-conex-accurate-ecn] Kuehlewind, M. and R. 608 Scheffenegger, "Accurate 609 ECN Feedback in TCP", draft 610 -kuehlewind-conex-accurate- 611 ecn-01 (work in progress), 612 October 2011. 614 [I-D.kuehlewind-conex-tcp-modifications] Kuehlewind, M. and R. 615 Scheffenegger, "TCP 616 modifications for 617 Congestion Exposure", draft 618 -kuehlewind-conex-tcp- 619 modifications-01 (work in 620 progress), October 2011. 622 [RFC2475] Blake, S., Black, D., 623 Carlson, M., Davies, E., 624 Wang, Z., and W. Weiss, "An 625 Architecture for 626 Differentiated Services", 627 RFC 2475, December 1998. 629 [RFC3168] Ramakrishnan, K., Floyd, 630 S., and D. Black, "The 631 Addition of Explicit 632 Congestion Notification 633 (ECN) to IP", RFC 3168, 634 September 2001. 636 [RFC6057] Bastian, C., Klieber, T., 637 Livingood, J., Mills, J., 638 and R. Woundy, "Comcast's 639 Protocol-Agnostic 640 Congestion Management 641 System", RFC 6057, 642 December 2010. 644 [TR-059] Anschutz, T., Ed., "DSL 645 Forum Technical Report TR- 646 059: Requirements for the 647 Support of QoS-Enabled IP 648 Services", September 2003. 650 [TR-101] Cohen, A., Ed. and E. 651 Schrum, Ed., "DSL Forum 652 Technical Report TR-101: 653 Migration to Ethernet-Based 654 DSL Aggregation", 655 April 2006. 657 Authors' Addresses 659 Bob Briscoe (editor) 660 BT 661 B54/77, Adastral Park 662 Martlesham Heath 663 Ipswich IP5 3RE 664 UK 666 Phone: +44 1473 645196 667 EMail: bob.briscoe@bt.com 668 URI: http://bobbriscoe.net/ 670 Richard Woundy (editor) 671 Comcast 672 1701 John F Kennedy Boulevard 673 Philadelphia, PA 19103 674 US 676 EMail: richard_woundy@cable.comcast.com 677 URI: http://www.comcast.com 679 Alissa Cooper (editor) 680 CDT 681 1634 Eye St. NW, Suite 1100 682 Washington, DC 20006 683 US 685 EMail: acooper@cdt.org