idnits 2.17.1 draft-ietf-conex-concepts-uses-05.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 (July 17, 2012) is 4295 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-briscoe-conex-data-centre-00 == Outdated reference: A later version (-03) exists of draft-briscoe-conex-initial-deploy-02 == Outdated reference: A later version (-13) exists of draft-ietf-conex-abstract-mech-04 == Outdated reference: A later version (-12) exists of draft-ietf-conex-destopt-02 == Outdated reference: A later version (-06) exists of draft-ietf-conex-mobile-00 == Outdated reference: A later version (-10) exists of draft-ietf-conex-tcp-modifications-02 == Outdated reference: A later version (-10) exists of draft-ietf-ledbat-congestion-09 -- No information found for draft-kuehlewind-tcpm-accurate-ecn-option - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 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: January 18, 2013 Comcast 6 A. Cooper, Ed. 7 CDT 8 July 17, 2012 10 ConEx Concepts and Use Cases 11 draft-ietf-conex-concepts-uses-05 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 January 18, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Congestion . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Congestion-Volume . . . . . . . . . . . . . . . . . . . . 5 62 2.3. Rest-of-Path Congestion . . . . . . . . . . . . . . . . . 6 63 2.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Core Use Case: Informing Traffic Management . . . . . . . . . 7 65 3.1. Use Case Description . . . . . . . . . . . . . . . . . . . 8 66 3.2. Additional Benefits . . . . . . . . . . . . . . . . . . . 9 67 3.3. Comparison with Existing Approaches . . . . . . . . . . . 9 68 4. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 11 69 5. Deployment Arrangements . . . . . . . . . . . . . . . . . . . 12 70 6. Experimental Considerations . . . . . . . . . . . . . . . . . 13 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 74 9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 15 75 10. Informative References . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 The power of Internet technology comes from multiplexing shared 80 capacity with packets rather than circuits. Network operators aim to 81 provide sufficient shared capacity, but when too much packet load 82 meets too little shared capacity, congestion results. Congestion 83 appears as either increased delay, dropped packets or packets 84 explicitly marked with Explicit Congestion Notification (ECN) 85 markings [RFC3168]. As described in Figure 1, congestion control 86 currently relies on the transport receiver detecting these 87 'Congestion Signals' and informing the transport sender in 88 'Congestion Feedback Signals.' The sender is then expected to reduce 89 its rate in response. 91 This document provides the entry point to the set of documentation 92 about the Congestion Exposure (ConEx) protocol. It focuses on the 93 motivation for including a ConEx marking at the IP layer. (A 94 companion document, [I-D.ietf-conex-abstract-mech], focuses on the 95 mechanics of the protocol.) Briefly, the idea is for the sender to 96 continually signal expected congestion in the headers of any data it 97 sends. To a first approximation, the sender does this by relaying 98 the 'Congestion Feedback Signals' back into the IP layer. They then 99 travel unchanged across the network to the receiver (shown as 'IP- 100 Layer-ConEx-Signals' in Figure 1). This enables IP layer devices on 101 the path to see information about the whole path congestion. 103 ,---------. ,---------. 104 |Transport| |Transport| 105 | Sender | . |Receiver | 106 | | /|___________________________________________| | 107 | ,-<---------------Congestion-Feedback-Signals--<--------. | 108 | | |/ | | | 109 | | |\ Transport Layer Feedback Flow | | | 110 | | | \ ___________________________________________| | | 111 | | | \| | | | 112 | | | ' ,-----------. . | | | 113 | | |_____________| |_______________|\ | | | 114 | | | IP Layer | | Data Flow \ | | | 115 | | | |(Congested)| \ | | | 116 | | | | Network |--Congestion-Signals--->-' | 117 | | | | Device | \| | 118 | | | | | /| | 119 | `----------->--(new)-IP-Layer-ConEx-Signals-------->| | 120 | | | | / | | 121 | |_____________| |_______________ / | | 122 | | | | |/ | | 123 `---------' `-----------' ' `---------' 124 Figure 1: The ConEx Protocol in the Internet Architecture 126 One of the key benefits of exposing this congestion information at 127 the IP layer is that it makes the information available to network 128 operators for use as input into their traffic management procedures. 129 A ConEx-enabled sender signals expected whole path congestion, which 130 is approximately the congestion at least a round trip time earlier as 131 reported by the receiver to the sender (Figure 1). The ConEx signal 132 is a mark in the IP header that is easy for any IP device to read. 133 Therefore a node performing traffic management can count congestion 134 as easily as it might count data volume today by simply counting the 135 volume of packets with ConEx markings. 137 ConEx-based traffic management can make highly efficient use of 138 capacity. In times of no congestion, all traffic management 139 restraints can be removed, leaving the network's full capacity 140 available to all its users. If some users on the network cause 141 disproportionate congestion, the traffic management function can 142 learn about this and directly limit those users' traffic in order to 143 protect the service of other users sharing the same capacity. ConEx- 144 based traffic management thus presents a step change in terms of the 145 options available to network operators for managing traffic on their 146 networks. 148 The remainder of this document explains the concepts behind ConEx and 149 how exposing congestion can significantly improve Internet traffic 150 management, among other benefits. Section 2 introduces a number of 151 concepts that are fundamental to understanding how ConEx-based 152 traffic management works. Section 3 shows how ConEx can be used for 153 traffic management, discusses additional benefits from such usage, 154 and compares ConEx-based traffic management to existing traffic 155 management approaches. Section 4 discusses other related use cases. 156 Section 5 briefly discusses deployment arrangements. The final 157 sections are standard RFC back matter. 159 The remainder of the core ConEx document suite consists of: 161 [I-D.ietf-conex-abstract-mech], which provides an abstract 162 encoding of ConEx signals, explains the ConEx audit and security 163 mechanisms, and describes incremental deployment features; 165 [I-D.ietf-conex-destopt], which specifies the IPv6 destination 166 option encoding for ConEx; 168 [I-D.ietf-conex-tcp-modifications], which specifies TCP sender 169 modifications for use of ConEx; 170 and the following documents, which describe some feasible 171 scenarios for deploying ConEx: 173 [I-D.briscoe-conex-initial-deploy], which describes a scenario 174 around a fixed broadband access network; 176 [I-D.ietf-conex-mobile], which describes a scenario around a 177 mobile communications provider; 179 [I-D.briscoe-conex-data-centre], which describes how ConEx 180 could be used for performance isolation between tenants of a 181 data centre. 183 2. Concepts 185 ConEx relies on a precise definition of congestion and a number of 186 newer concepts that are introduced in this section. Definitions are 187 summarized in Section 2.4. 189 2.1. Congestion 191 Despite its central role in network control and management, 192 congestion is a remarkably difficult concept to define. Experts in 193 different disciplines and with different perspectives define 194 congestion in a variety of ways [Bauer09]. 196 The definition used for the purposes of ConEx is expressed as the 197 probability of packet loss (or the probability of packet marking if 198 ECN is in use). This definition focuses on how congestion is 199 measured, rather than describing congestion as a condition or state. 201 2.2. Congestion-Volume 203 The metric that ConEx exposes is congestion-volume: the volume of 204 bytes dropped or ECN-marked in a given period of time. Counting 205 congestion-volume allows each user to be held responsible for his or 206 her contribution to congestion. Congestion-volume can only be a 207 property of traffic, whereas congestion can be a property of traffic 208 or a property of a link or a path. 210 To understand congestion-volume, consider a simple example. Imagine 211 Alice sends 1GB of a file while the loss-probability is a constant 212 0.2%. Her contribution to congestion -- her congestion-volume -- is 213 1GB x 0.2% = 2MB. If she then sends another 3GB of the file while 214 the loss-probability is 0.1%, this adds 3MB to her congestion-volume. 215 Her total contribution to congestion is then 2MB+3MB = 5MB. 217 Fortunately, measuring Alice's congestion-volume on a real network 218 does not require the kind of arithmetic shown above because 219 congestion-volume can be directly measured by counting the total 220 volume of Alice's traffic that gets discarded or ECN-marked. (A 221 queue with varying percentage loss does these multiplications and 222 additions inherently.) With ConEx, network operators can count 223 congestion-volume using techniques very similar to those they use for 224 counting volume. 226 2.3. Rest-of-Path Congestion 228 At a particular measurement point within a network, "rest-of-path 229 congestion" (also known as "downstream congestion") is the level of 230 congestion that a traffic flow is expected to experience between the 231 measurement point and its final destination. "Upstream congestion" 232 is the congestion experienced up to the measurement point. 234 If traffic is ECN-capable, ECN signals monitored in the middle of a 235 network will indicate the congestion experienced so far on the path 236 (upstream congestion). In contrast, the ConEx signals inserted into 237 IP headers as shown in Figure 1 indicate the congestion along a whole 238 path from transport source to transport destination. Therefore if a 239 measurement point detects both of these signals, it can subtract the 240 level of ECN (upstream congestion) from the level of ConEx (whole 241 path) to derive a measure of the congestion that packets are likely 242 to experience between the monitoring point and their destination 243 (rest-of-path congestion). A measurement point can calculate this 244 measurement in the aggregate, across all flows. 246 A network monitor can usually accurately measure upstream congestion 247 only if the traffic it observes is ECN-capable. 248 [I-D.ietf-conex-abstract-mech] has further discussion of the 249 constraints around the network's ability to measure upstream and 250 rest-of-path congestion in these circumstances. However, there are a 251 number of intial deployment arrangements that benefit from ConEx but 252 work without ECN (see Section 5). 254 2.4. Definitions 256 Congestion: In general, congestion occurs when any user's traffic 257 suffers loss, ECN marking, or increased delay as a result of one 258 or more network resources becoming overloaded. For the purposes 259 of ConEx, congestion is measured using the concrete signals 260 provided by loss and ECN markings (delay is not considered). 261 Congestion is measured as the probability of loss or the 262 probability of ECN marking, usually expressed as a dimensionless 263 percentage. 265 Congestion-volume: For any granularity of traffic (packet, flow, 266 aggregate, link, etc.), the volume of bytes dropped or ECN-marked 267 in a given period of time. Conceptually, data volume multiplied 268 by the congestion each packet of the volume experienced. Usually 269 expressed in bytes (or MB or GB). 271 Congestion policer: A logical entity that allows a network operator 272 to monitor each user's congestion-volume and enforce congestion- 273 volume limits (discussed in Section 3.1). 275 Rest-of-path congestion (or downstream congestion): The congestion a 276 flow of traffic is expected to experience on the remainder of its 277 path. In other words, at a measurement point in the network, the 278 rest-of-path congestion is the congestion the traffic flow has yet 279 to experience as it travels from that point to the receiver. This 280 is usually expressed as a dimensionless percentage. 282 Upstream congestion: The accumulated congestion experienced by a 283 traffic flow thus far, relative to a point along its path. In 284 other words, at a measurement point in the network the upstream 285 congestion is the accumulated congestion the traffic flow has 286 experienced as it travels from the sender to that point. At the 287 receiver this is equivalent to the end-to-end congestion level 288 that (usually) is reported back to the sender. This is usually 289 expressed as a dimensionless percentage. 291 Network operators (or providers): Operator of a residential, 292 commercial, enterprise, campus or other network. 294 User: The contractual entity that represents an individual, 295 household, business, or institution that uses the service of a 296 network operator. There is no implication that the contract has 297 to be commercial; for instance, the users of a university or 298 enterprise network service could be students or employees who do 299 not pay for access but may be required to comply with some form of 300 contract or acceptable use policy. There is also no implication 301 that every user is an end user. Where two networks form a 302 customer-provider relationship, the term user applies to the 303 customer network. 305 [I-D.ietf-conex-abstract-mech] gives further definitions for aspects 306 of ConEx related to protocol mechanisms. 308 3. Core Use Case: Informing Traffic Management 310 This section explains how ConEx could be used as the basis for 311 traffic management, highlights additional benefits derived from 312 having ConEx-aware nodes on the network, and compares ConEx-based 313 traffic management to existing approaches. 315 3.1. Use Case Description 317 One of the key benefits that ConEx can deliver is in helping network 318 operators to improve how they manage traffic on their networks. 319 Consider the common case of a commercial broadband network where a 320 relatively small number of users place disproportionate demand on 321 network resources, at times resulting in congestion. The network 322 operator seeks a way to manage traffic such that the traffic that 323 contributes more to congestion bears more of the brunt of the 324 management. 326 Assuming ConEx signals are visible at the IP layer, the network 327 operator can accomplish this by placing a congestion policer at an 328 enforcement point within the network and configuring it with a 329 traffic management policy that monitors each user's contribution to 330 congestion. As described in [I-D.ietf-conex-abstract-mech] and 331 elaborated in [CongPol], one way to implement a congestion policer is 332 in a similar way to a bit-rate policer, except that it monitors 333 congestion-volume (based on IP layer ConEx signals) rather than bit- 334 rate. When implemented as a token bucket, the tokens provide users 335 with the right to cause bits of congestion-volume, rather than to 336 send bits of data volume. The fill rate represents each user's 337 congestion-volume quota. 339 The congestion policer monitors the ConEx signals of the traffic 340 entering the network. As long as the network remains uncongested and 341 users stay within their quotas, no action is taken. When the network 342 becomes congested and a user exhausts his quota, some action is taken 343 against the traffic that breached the quota in accordance with the 344 network operator's traffic management policy. For example, the 345 traffic may be dropped, delayed, or marked with a lower QoS class. 346 In this way, traffic is managed according to its contribution to 347 congestion -- not some application- or flow-specific policy -- and is 348 not managed at all during times of no congestion. 350 As an example of how a network operator might employ a ConEx-based 351 traffic management system, consider a typical DSL network 352 architecture (as elaborated in [TR-059] and [TR-101]). Traffic is 353 routed from regional and global IP networks to an operator-controlled 354 IP node, the Broadband Remote Access Server (BRAS). From the BRAS, 355 traffic is delivered to access nodes. The BRAS carries enhanced 356 functionality including IP QoS and traffic management capabilities. 358 By deploying a congestion policer at the BRAS location, the network 359 operator can measure the congestion-volume created by users within 360 the access nodes and police misbehaving users before their traffic 361 affects others on the access network. The policer would be 362 provisioned with a traffic management policy, perhaps directing the 363 BRAS to drop packets from users that exceed their congestion-volume 364 quotas during times of congestion. Those users' apps would be likely 365 to react in the typical way to drops, backing off (assuming at least 366 some use TCP), and thereby lowering the users' congestion-volumes 367 back within the quota limits. If none of a user's apps responds, the 368 policer would continue to increase focused drops and effectively 369 enforce its own congestion control. 371 3.2. Additional Benefits 373 The ConEx-based approach to traffic management has a number of 374 benefits in addition to efficient management of traffic. It provides 375 incentives for users to make use of "scavenger" transport protocols, 376 such as [I-D.ietf-ledbat-congestion], that provide ways for bulk- 377 transfer applications to rapidly yield when interactive applications 378 require capacity (thereby "scavenging" remaining bandwidth). With a 379 congestion policer in place as described in Section 3.1, users of 380 these protocols will be less likely to run afoul of the network 381 operator's traffic management policy than those whose bulk-transfer 382 applications generate the same volume of traffic without being 383 sensitive to congestion. In short, two users who produce similar 384 traffic volumes over the same time interval may produce different 385 congestion-volumes if one of them is using a scavenger transport 386 protocol and the other is not; in that situation the scavenger user's 387 traffic is less likely to be managed by the network operator. 389 ConEx-based traffic management also makes it possible for a user to 390 control the relative performance among its own traffic flows. If a 391 user wants some flows to have more bandwidth than others, it can 392 reduce the rate of some traffic so that it consumes less congestion- 393 volume "budget", leaving more congestion-volume "budget" for the user 394 to "spend" on making other traffic go faster. This approach is most 395 relevant if congestion is signalled by ECN, because no impairment due 396 to loss is involved and delay can remain low. 398 3.3. Comparison with Existing Approaches 400 A variety of approaches already exist for network operators to manage 401 congestion, traffic, and the disproportionate usage of scarce 402 capacity by a small number of users. Common approaches can be 403 categorized as rate-based, volume-based, or application-based. 405 Rate-based approaches constrain the traffic rate per user or per 406 network. A user's peak and average (or "committed") rate may be 407 limited. These approaches have the potential to either over- or 408 under-constrain the network, suppressing rates even when the network 409 is uncongested or not suppressing them enough during heavy usage 410 periods. 412 Round-robin scheduling and fair queuing were developed to address 413 these problems. They equalize relative rates between active users 414 (or flows) at a known bottleneck. The bit-rate allocated to any one 415 user depends on the number of active users at each instant. The 416 drawback of these approaches is that they favor heavy users over 417 light users over time, because they do not have any memory of usage. 418 Heavy users will be active at every instant whereas light users will 419 only occupy their share of the link occassionally, but bit-rate is 420 shared instant by instant. 422 Volume-based approaches measure the overall volume of traffic a user 423 sends (and/or receives) over time. Users may be subject to an 424 absolute volume cap (for example, 10GB per month) or the "heaviest" 425 users may be sanctioned in some other manner. Many providers use 426 monthly volume limits and count volume regardless of whether the 427 network is congested or not, creating the potential for over- or 428 under-constraining problems, as with the original rate-based 429 approaches. 431 ConEx-based approaches, by comparison, only react during times of 432 congestion and in proportion to each user's congestion contribution, 433 making more efficient use of capacity and more proportionate 434 management decisions. 436 Unlike ConEx-based approaches, neither rate-based nor volume-based 437 approaches provide incentives for applications to use scavenger 438 transport protocols. They may even penalize users of applications 439 that employ scavenger transports for the large amount of volume they 440 send, rather than rewarding them for carefully avoiding congestion 441 while sending it. While the volume-based approach described in 442 Comcast's Protocol-Agnostic Congestion Management System [RFC6057] 443 aims to overcome the over/under-constraining problem by only 444 measuring volume and triggering traffic management action during 445 periods of high utilization, it still does not provide incentives to 446 use scavenger transports because congestion-causing volume cannot be 447 distinguished from volume overall. ConEx provides this ability. 449 Application-based approaches use deep packet inspection or other 450 techniques to determine what application a given traffic flow is 451 associated with. Network operators may then use this information to 452 rate-limit or otherwise sanction certain applications, in some cases 453 only during peak hours. These approaches suffer from being at odds 454 with IPsec and some application-layer encryption, and they may raise 455 additional policy concerns. In contrast, ConEx offers an 456 application-agnostic metric to serve as the basis for traffic 457 management decisions. 459 The existing types of approaches share a further limitation that 460 ConEx can help to overcome: performance uncertainty. Flat-rate 461 pricing plans are popular because users appreciate the certainty of 462 having their monthly bill amount remain the same for each billing 463 period, allowing them to plan their costs accordingly. But while 464 flat-rate pricing avoids billing uncertainty, it creates performance 465 uncertainty: users cannot know whether the performance of their 466 connections is being altered or degraded based on how the network 467 operator is attempting to manage congestion. By exposing congestion 468 information at the IP layer, ConEx instead provides a metric that can 469 serve as an open, transparent basis for traffic management policies 470 that both providers and their customers can measure and verify. It 471 can be used to reduce the performance uncertainty that some users 472 currently experience. 474 4. Other Use Cases 476 ConEx information can be put to a number of uses other than informing 477 traffic management. These include: 479 Informing inter-operator contracts: ConEx information is made 480 visible to every IP node, including border nodes between networks. 481 Network operators can use ConEx combined with ECN markings to 482 measure how much traffic from each network contributes to 483 congestion in the other. As such, congestion-volume could be 484 included as a metric in inter-operator contracts, just as volume 485 or bit-rate are included today. This would not be an initial 486 deployment scenario, unless ECN became widely deployed. 488 Enabling more efficient capacity provisioning: Section 3.2 explained 489 how operators can use ConEx-based traffic management to encourage 490 use of scavenger transport protocols, which significantly improves 491 the performance of interactive applications while still allowing 492 heavy users to transfer high volumes. Here we explain how this 493 can also benefit network operators. 495 Today, when loss, delay or averaged utilization exceeds a certain 496 threshold, some operators just buy more capacity without 497 attempting to manage the traffic. Other operators prefer to limit 498 a minority of heavy users at peak times, but they still eventually 499 buy more capacity when utilization rises. 501 With ConEx-based traffic management, a network operator should be 502 able to provision capacity more efficiently. An operator could 503 benefit from this in a variety of ways. For example, the operator 504 could add capacity as it would do without ConEx, but deliver 505 better quality of service for its users. Or the operator could 506 delay adding capacity while delivering similar quality of service 507 to what it currently provides. 509 5. Deployment Arrangements 511 ConEx is designed so that it can be incrementally deployed in the 512 Internet and still be valuable for early adopters. As long as some 513 senders are ConEx-enabled, a network on the path can unilaterally use 514 ConEx-aware policy devices for traffic management; no changes to 515 network forwarding elements are needed and ConEx still works if there 516 are other networks on the path that are unaware of ConEx marks. 518 The above two steps seem to represent a stand-off where neither step 519 is useful until the other has made the first move: i) some sending 520 hosts must be modifed to give information to the network and ii) a 521 network must deploy policy devices to monitor this information and 522 act on it. Nonetheless, the developer of a scavenger transport 523 protocol like LEDBAT does stand to benefit from deploying ConEx. In 524 this case the developer makes the first move, expecting it will 525 prompt at least some networks to move in response, using the ConEx 526 information to reward users of the scavenger transport protocol. 528 On the host side, we have already shown (Figure 1) how the sender 529 piggy-backs ConEx signals on normal data packets to re-insert 530 feedback about packet drops (and/or ECN) back into the IP layer. In 531 the case of TCP, [I-D.ietf-conex-tcp-modifications] proposes the 532 required sender modifications. ConEx works with any TCP receiver as 533 long as it uses SACK, which most do. There is a receiver 534 optimisation [I-D.tcpm-accurate-ecn] that improves ConEx precision 535 when using ECN, but ConEx can still use ECN without it. Networks can 536 make use of ConEx even if the implementations of some of the 537 transport protocols on a host do not support ConEx (e.g. the 538 implementation of DNS over UDP might not support ConEx, while perhaps 539 RTP over UDP and TCP will). 541 On the network side the provider solely needs to place ConEx 542 congestion policers at each ingress to its network, in a similar 543 arrangement to the edge-policed architecture of Diffserv [RFC2475]. 545 A sender can choose whether to send packets that support ConEx or 546 packets that don't. ConEx-enabled packets bring information to the 547 policer about congestion expected on the rest of the path beyond the 548 policer. Packets that do not support ConEx bring no such 549 information. Therefore the network will tend to conservatively rate- 550 limit non-ConEx-enabled packets in order to manage the unknown risk 551 of congestion. In contrast, a network doesn't normally need to rate- 552 limit ConEx-enabled packets unless they reveal a persistently high 553 contribution to congestion. This natural tendency for networks to 554 favour senders that provide ConEx information reinforces ConEx 555 deployment. 557 Feasible initial deployment scenarios exist for a broadband access 558 network [I-D.briscoe-conex-initial-deploy], a mobile communications 559 network [I-D.ietf-conex-mobile], and a multi-tenant data centre 560 [I-D.briscoe-conex-data-centre]. The first two of these scenarios 561 are believed to work well without ECN support, while the data center 562 scenario works best with ECN (where it may be more likely for ECN to 563 be deployed in the future). 565 The above gives only the most salient aspects of ConEx deployment. 566 For further detail, [I-D.ietf-conex-abstract-mech] describes the 567 incremental deployment features of the ConEx protocol and the 568 components that need to be deployed for ConEx to work. 570 6. Experimental Considerations 572 ConEx is initially designed as an experimental protocol because it 573 makes an ambitious change at the interoperability (IP) layer, so no 574 amount of careful design can foresee all the potential feature 575 interactions with other uses of IP. This section identifies a number 576 of questions that would be useful to answer through well-designed 577 experiments: 579 o Are the compromises that were made in order to fit the ConEx 580 encoding into IP (for example, that the initial design was solely 581 for IPv6 and not for IPv4, and that the encoding has limited 582 visibility when tunnelled [I-D.ietf-conex-destopt]) the right 583 ones? 585 o Is it possible to combine techniques for distinguishing self- 586 congestion from shared congestion with ConEx-based traffic 587 management such that users are not penalized for congestion that 588 does not impact others on the network? Are other techniques 589 needed? 591 o If ECN deployment remains patchy, are the proposed initial ConEx 592 deployment scenarios (Section 5) still useful enough to kick-start 593 deployment? Is audit effective when based on loss at a primary 594 bottleneck? Can rest-of-path congestion be approximated 595 accurately enough without ECN? Are there other useful deployment 596 scenarios? 598 o In practice, how does traffic management using ConEx compare with 599 traditional techniques (Section 3.3)? Does it give the benefits 600 claimed in Section 3.1 and Section 3.2? 602 o Approaches are proposed for congestion policing of ConEx traffic 603 alongside existing management (or lack thereof) of non-ConEx 604 traffic, including UDP traffic [I-D.ietf-conex-abstract-mech]. 605 Are they strategy-proof against users selectively using both? Are 606 there better transition strategies? 608 o Audit devices have been designed and implemented to assure ConEx 609 signal integrity [I-D.ietf-conex-abstract-mech]. Do they achieve 610 minimal false hits and false misses in a wide range of traffic 611 scenarios? Are there new attacks? Are there better audit designs 612 to defend against these? 614 ConEx is intended to be a generative technology that might be used 615 for unexpected purposes unforeseen by the designers. Therefore this 616 list of experimental considerations is not intended to be exhaustive. 618 7. Security Considerations 620 This document does not specify a mechanism, it merely motivates 621 congestion exposure at the IP layer. Therefore security 622 considerations are described in the companion document that gives an 623 abstract description of the ConEx protocol and the components that 624 would use it [I-D.ietf-conex-abstract-mech]. 626 8. IANA Considerations 628 This document does not require actions by IANA. 630 9. Acknowledgments 632 Bob Briscoe was partly funded by Trilogy, a research project (ICT- 633 216372) supported by the European Community under its Seventh 634 Framework Programme. The views expressed here are those of the 635 author only. 637 The authors would like to thank the many people that have commented 638 on this document: Bernard Aboba, Mikael Abrahamsson, Joao Taveira 639 Araujo, Marcelo Bagnulo Braun, Steve Bauer, Caitlin Bestler, Steven 640 Blake, Louise Burness, Ken Carlberg, Nandita Dukkipati, Dave McDysan, 641 Wes Eddy, Matthew Ford, Ingemar Johansson, Georgios Karagiannis, 642 Mirja Kuehlewind, Dirk Kutscher, Zhu Lei, Kevin Mason, Matt Mathis, 643 Michael Menth, Chris Morrow, Tim Shepard, Hannes Tschofenig and 644 Stuart Venters. Please accept our apologies if your name has been 645 missed off this list. 647 9.1. Contributors 649 Philip Eardley and Andrea Soppera made helpful text contributions to 650 this document. 652 The following co-edited this document through most of its life: 654 Toby Moncaster 655 Computer Laboratory 656 William Gates Building 657 JJ Thomson Avenue 658 Cambridge, CB3 0FD 659 UK 660 EMail: toby.moncaster@cl.cam.ac.uk 662 John Leslie 663 JLC.net 664 10 Souhegan Street 665 Milford, NH 03055 666 US 667 EMail: john@jlc.net 669 10. Informative References 671 [Bauer09] Bauer, S., Clark, D., and W. 672 Lehr, "The Evolution of Internet 673 Congestion", 2009. 675 [CongPol] Briscoe, B., Jacquet, A., and T. 676 Moncaster, "Policing Freedom to 677 Use the Internet Resource Pool", 678 RE-Arch 2008 hosted at the 2008 679 CoNEXT conference , 680 December 2008. 682 [I-D.briscoe-conex-data-centre] Briscoe, B. and M. Sridharan, 683 "Network Performance Isolation in 684 Data Centres using Congestion 685 Exposure (ConEx)", draft-briscoe- 686 conex-data-centre-00 (work in 687 progress), July 2012. 689 [I-D.briscoe-conex-initial-deploy] Briscoe, B., "Initial Congestion 690 Exposure (ConEx) Deployment 691 Examples", draft-briscoe-conex- 692 initial-deploy-02 (work in 693 progress), March 2012. 695 [I-D.ietf-conex-abstract-mech] Mathis, M. and B. Briscoe, 696 "Congestion Exposure (ConEx) 697 Concepts and Abstract Mechanism", 698 draft-ietf-conex-abstract-mech-04 699 (work in progress), March 2012. 701 [I-D.ietf-conex-destopt] Krishnan, S., Kuehlewind, M., and 702 C. Ucendo, "IPv6 Destination 703 Option for Conex", 704 draft-ietf-conex-destopt-02 (work 705 in progress), March 2012. 707 [I-D.ietf-conex-mobile] Kutscher, D., Mir, F., Winter, 708 R., Krishnan, S., Zhang, Y., and 709 C. Bernardos, "Mobile 710 Communication Congestion Exposure 711 Scenario", 712 draft-ietf-conex-mobile-00 (work 713 in progress), July 2012. 715 [I-D.ietf-conex-tcp-modifications] Kuehlewind, M. and R. 716 Scheffenegger, "TCP modifications 717 for Congestion Exposure", draft- 718 ietf-conex-tcp-modifications-02 719 (work in progress), May 2012. 721 [I-D.ietf-ledbat-congestion] Hazel, G., Iyengar, J., 722 Kuehlewind, M., and S. Shalunov, 723 "Low Extra Delay Background 724 Transport (LEDBAT)", 725 draft-ietf-ledbat-congestion-09 726 (work in progress), October 2011. 728 [I-D.tcpm-accurate-ecn] Kuehlewind, M. and R. 729 Scheffenegger, "Accurate ECN 730 Feedback Option in TCP", draft- 731 kuehlewind-tcpm-accurate-ecn- 732 option-01 (work in progress), 733 July 2012. 735 [RFC2475] Blake, S., Black, D., Carlson, 736 M., Davies, E., Wang, Z., and W. 737 Weiss, "An Architecture for 738 Differentiated Services", 739 RFC 2475, December 1998. 741 [RFC3168] Ramakrishnan, K., Floyd, S., and 742 D. Black, "The Addition of 743 Explicit Congestion Notification 744 (ECN) to IP", RFC 3168, 745 September 2001. 747 [RFC6057] Bastian, C., Klieber, T., 748 Livingood, J., Mills, J., and R. 749 Woundy, "Comcast's Protocol- 750 Agnostic Congestion Management 751 System", RFC 6057, December 2010. 753 [TR-059] Anschutz, T., Ed., "DSL Forum 754 Technical Report TR-059: 755 Requirements for the Support of 756 QoS-Enabled IP Services", 757 September 2003. 759 [TR-101] Cohen, A., Ed. and E. Schrum, 760 Ed., "DSL Forum Technical Report 761 TR-101: Migration to Ethernet- 762 Based DSL Aggregation", 763 April 2006. 765 Authors' Addresses 767 Bob Briscoe (editor) 768 BT 769 B54/77, Adastral Park 770 Martlesham Heath 771 Ipswich IP5 3RE 772 UK 774 Phone: +44 1473 645196 775 EMail: bob.briscoe@bt.com 776 URI: http://bobbriscoe.net/ 778 Richard Woundy (editor) 779 Comcast 780 1701 John F Kennedy Boulevard 781 Philadelphia, PA 19103 782 US 784 EMail: richard_woundy@cable.comcast.com 785 URI: http://www.comcast.com 786 Alissa Cooper (editor) 787 CDT 788 1634 Eye St. NW, Suite 1100 789 Washington, DC 20006 790 US 792 EMail: acooper@cdt.org