idnits 2.17.1 draft-mathis-conex-abstract-mech-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 (October 19, 2010) is 4938 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'FairerFaster' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'Re-fb' is defined on line 669, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-briscoe-tsvwg-re-ecn-tcp-motivation-01 == Outdated reference: A later version (-09) exists of draft-briscoe-tsvwg-re-ecn-tcp-08 == Outdated reference: A later version (-02) exists of draft-moncaster-conex-concepts-uses-01 == Outdated reference: A later version (-10) exists of draft-ietf-ledbat-congestion-02 -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Congestion Exposure (ConEx) M. Mathis 3 Working Group Google 4 Internet-Draft B. Briscoe 5 Intended status: Informational BT 6 Expires: April 22, 2011 October 19, 2010 8 Congestion Exposure (ConEx) Concepts and Abstract Mechanism 9 draft-mathis-conex-abstract-mech-00 11 Abstract 13 This document describes an abstract mechanism by which senders inform 14 the network about the congestion encountered by packets earlier in 15 the same flow. Today, the network may signal congestion to the 16 receiver by ECN markings or by dropping packets, and the receiver may 17 pass this information back to the sender in transport-layer feedback. 18 The mechanism to be developed by the ConEx WG will enable the sender 19 to also relay this congestion information back into the network in- 20 band at the IP layer, such that the total level of congestion is 21 visible to all IP devices along the path, from where it could, for 22 example, be provided as input to traffic management. 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 April 22, 2011. 41 Copyright Notice 43 Copyright (c) 2010 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Requirements for the ConEx Signal . . . . . . . . . . . . . . 5 61 3. Representing Congestion Exposure . . . . . . . . . . . . . . . 7 62 3.1. Strawman Encoding . . . . . . . . . . . . . . . . . . . . 7 63 3.2. ECN Based Encoding . . . . . . . . . . . . . . . . . . . . 8 64 3.2.1. ECN Changes . . . . . . . . . . . . . . . . . . . . . 8 65 3.3. Abstract Encoding . . . . . . . . . . . . . . . . . . . . 9 66 3.3.1. Independent Bits . . . . . . . . . . . . . . . . . . . 9 67 3.3.2. Codepoint Encoding . . . . . . . . . . . . . . . . . . 9 68 4. Congestion Exposure Components . . . . . . . . . . . . . . . . 10 69 4.1. Modified Senders . . . . . . . . . . . . . . . . . . . . . 10 70 4.2. Receivers (Optionally Modified) . . . . . . . . . . . . . 10 71 4.3. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.4. Policy Devices . . . . . . . . . . . . . . . . . . . . . . 11 73 4.4.1. Congestion Policers . . . . . . . . . . . . . . . . . 12 74 4.4.2. Other Policy Devices . . . . . . . . . . . . . . . . . 12 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 79 9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 13 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 One of the required functions of a transport protocol is controlling 87 congestion in the network. There are three techniques in use today 88 for the network to signal congestion to a transport: 90 o The most common congestion signal is packet loss. When congested, 91 the network simply discards some packets either as part of an 92 explicit control function [RFC2309] or as the consequence of a 93 queue overflow or other resource starvation. The transport 94 receiver detects that some data is missing and signals such 95 through transport acknowledgments to the transport sender (e.g. 96 TCP SACK options). The sender performs the appropriate congestion 97 control rate reduction (e.g. [RFC5681] for TCP) and, if it is a 98 reliable transport, it retransmits the missing data. 100 o If the transport supports explicit congestion notification (ECN) 101 [RFC3168] or pre-congestion notification (PCN) [RFC5670] , the 102 transport sender indicates this by setting an ECN-capable 103 transport (ECT) codepoint in every packet. Network devices can 104 then explicitly signal congestion to the receiver by setting ECN 105 bits in the IP header of such packets. The transport receiver 106 communicates these ECN signals back to the sender, which then 107 performs the appropriate congestion control rate reduction. 109 o Some experimental transport protocols and TCP variants [Vegas] 110 sense queuing delays in the network and reduce their rate before 111 the network has to signal congestion using loss or ECN. A purely 112 delay-sensing transport will tend to be pushed out by other 113 competing transports that do not back off until they have driven 114 the queue into loss. Therefore, modern delay-sensing algorithms 115 use delay in some combination with loss to signal congestion (e.g. 116 LEDBAT [I-D.ietf-ledbat-congestion], Compound 117 [I-D.sridharan-tcpm-ctcp]). In the rest of this document, we will 118 confine the discussion to concrete signals of congestion such as 119 loss and ECN. We will not discuss delay-sensing further, because 120 it can only avoid these more concrete signals of congestion in 121 some circumstances. 123 In all cases the congestion signals follow the route indicated in 124 Figure 1. A congested network device sends a signal in the data 125 stream on the forward path to the transport receiver, the receiver 126 passes it back to the sender through transport level feedback, and 127 the sender makes some congestion control adjustment. 129 This document proposes to extend the capabilities of the Internet 130 protocol suite with the addition of a ConEx Signal that, to a first 131 approximation, relays the congestion information from the transport 132 sender back through the internetwork layer. That signal is shown in 133 Figure 1. It would be visible to all internetwork layer devices 134 along the forward (data) path and is intended to support a number of 135 new policy-controlled mechanisms that might be used to manage 136 traffic. 137 123456789012345678901234567890123456789012345678901234567890123456789 138 +---------+ +---------+ 139 | |<==Feedback Path==============================<| | 140 | |<--Transport Layer returned Congestion Signal-<| | 141 | | | | 142 |Transport| |Transport| 143 | Sender |>---------(new)-IP layer ConEx Signal--------->| Receiver| 144 | | (Carried in Data Packet Headers) | | 145 | | +-----------+ | | 146 | |>=Data=Path=>|(Congested)|>=====Data=Path=====>| | 147 | | | Network |>-Congestion-Signal->| | 148 | | | Device | | | 149 +---------+ +-----------+ +---------+ 151 Not shown are policy devices along the data path that observe the 152 ConEx Signal, and use the information to monitor or manage traffic. 153 These are discussed in Section 4.4. 155 Figure 1 157 1.1. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119 [RFC2119]. 163 ConEx signals in IP packet headers from the sender to the network 164 {ToDo: These are placeholders for whatever words we decide to use}: 166 Not-ConEx: The transport is not ConEx-capable 168 ConEx-Capable: The transport is ConEx-Capable. This is the opposite 169 of Not-ConEx and implies one of the following signals 171 Re-Echo-Loss: (aka Purple) The transport has experienced a loss 173 Re-Echo-ECN: (aka Black) The transport has experienced an ECN 174 mark 176 Credit: (aka Green) The transport is building up credit to allow 177 for any future delay in expected ConEx signals 179 ConEx-Not-Marked: The transport is ConEx-capable but is signaling 180 none of Re-Echo-Loss, Re-Echo-ECN or Credit 182 ConEx-Marked: At least one of Re-Echo-Loss, Re-Echo-ECN or 183 Credit. 185 2. Requirements for the ConEx Signal 187 Ideally, all the following requirements would be met by a Congestion 188 Exposure Signal. However it is already known that some compromises 189 will be necessary, therefore all the requirements are expressed with 190 the keyword 'SHOULD' rather than 'MUST'. The only mandatory 191 requirement is that a concrete protocol description MUST give sound 192 reasoning if it chooses not to meet any of these requirements: 194 a. The ConEx Signal SHOULD be visible to internetwork layer devices 195 along the entire path from the transport sender to the transport 196 receiver. Equivalently, it SHOULD be present in the IPv4 or IPv6 197 header, and in the outermost IP header if using IP in IP 198 tunneling. The ConEx Signal SHOULD be immutable once set by the 199 transport sender. A corollary of these requirements is that 200 existing (legacy) networking gear SHOULD pass the Congestion 201 Exposure Signal silently without modification. 203 b. The ConEx Signal SHOULD be useful under only partial deployment. 204 A minimal deployment SHOULD only require changes to transport 205 senders. Furthermore, partial deployment SHOULD create 206 incentives for additional deployment, both in terms of enabling 207 ConEx on more devices and adding richer features to existing 208 devices. Nonetheless, ConEx deployment need never be universal, 209 and it is anticipated that some hosts and some transports may 210 never support the ConEx Protocol and some networks may never use 211 the ConEx Signals. 213 c. The ConEx Signal SHOULD be accurate. In potentially hostile 214 environments such as the public Internet, it SHOULD be possible 215 for techniques to be deployed to audit the Congestion Exposure 216 Signal by comparing it to the actual congestion signals on the 217 forward data path. The auditing mechanism must have a capability 218 for providing sufficient disincentives against misreported 219 congestion, such as by throttling traffic that reports less 220 congestion than it is actually experiencing. 222 d. The ConEx Signal SHOULD be timely. There will be a delay between 223 the time when an auditing device sees an actual congestion signal 224 and when it sees the subsequent Congestion Exposure Signal from 225 the sender. The minimum delay will be one round trip, but it may 226 be much longer depending on the transport's choice of feedback 227 delay (consider RTCP [RFC3550] for example). It is not practical 228 to expect auditing devices in the network to make allowance for 229 such feedback delays. Instead, the sender SHOULD be able to send 230 ConEx signals in advance, as 'credit' for any audit device to 231 hold as a balance against the risk of congestion during the 232 feedback delay. This design choice simplifies auditing devices 233 and correctly makes the transport responsible for both minimizing 234 feedback delay and minimizing sharp increases in packets in 235 flight that would risk causing excessive congestion to others. 236 This issue is discussed in more detail in Section 4.3. 238 It is important to note that the auditing requirement implies a 239 number of additional constraints: The basic auditing technique is to 240 count both actual congestion signals and ConEx Signals someplace 241 along the data path: 243 o For congestion signaled by ECN, auditing is most accurate when 244 located near the transport receiver. Within any flow or aggregate 245 of flows, the total volume of ECN marked data seen near the 246 receiver should always be equal to or less than the volume of data 247 tagged with ConEx Signals. 249 o For congestion signaled by loss, totally accurate auditing is not 250 believed to be possible in the general case, because it involves a 251 network node detecting the absence of some packets, when it cannot 252 necessarily see the transport protocol sequence numbers and when 253 the missing packets might simply be taking a different route. But 254 there are common cases where sufficient audit accuracy should be 255 possible: 257 * For non-IPsec traffic conforming to standard TCP sequence 258 numbering on a single path, an auditor could detect losses by 259 observing both the original transmission and the retransmission 260 after the loss. Such auditing would be most accurate near the 261 sender. 263 * For networks designed so that losses predominantly occur under 264 the management of one IP-aware node on the path, the auditor 265 could be located at this bottleneck. It could simply compare 266 ConEx Signals with actual local losses. This is a good model 267 for most consumer access networks and audit accuracy could well 268 be sufficient even if losses occasionally occurred at other 269 nodes in the network, such as border gateways (see Section 4.3 270 for details). 272 Given that loss-based and ECN-based ConEx might sometimes be best 273 audited at different locations, having distinct encodings would widen 274 the design space for the auditing function. 276 3. Representing Congestion Exposure 278 Most protocol specifications start with a description of packet 279 formats and codepoints with their associated meanings. This document 280 does not: It is already known that choosing the encoding for the 281 ConEx Signal is likely to entail some engineering compromises that 282 have the potential to reduce the protocol's usefulness in some 283 settings. Rather than making these engineering choices prematurely, 284 this document side steps the encoding problem by describing an 285 abstract representation of ConEx Signals. All of the elements of the 286 protocol can be defined in terms of this abstract representation. 287 Most important, the preliminary use cases for the protocol are 288 described in terms of the abstract representation in companion 289 documents [I-D.conex-concepts-uses]. 291 Once we have some example use cases we can evaluate different 292 encoding schemes. Since these schemes are likely to include some 293 conflated code points, some information will be lost resulting in 294 weakening or disabling some of the algorithms and eliminating some 295 use cases. 297 The goal of this approach is to be as complete as possible for 298 discovering the potential usage and capabilities of the ConEx 299 protocol, so we have some hope of making optimal design decisions 300 when choosing the encoding. 302 3.1. Strawman Encoding 304 As an aid to the reader, it might be helpful to describe a naive 305 strawman encoding of the ConEx protocol described solely in terms of 306 TCP: set the Reserved bit in the IPv4 header (bit 48 counting from 307 zero [RFC0791]--aka the "evil bit" [RFC3514]) on all retransmissions 308 or once per ECN signaled window reduction. Clearly network devices 309 along the forward path can see this bit and act on it. For example 310 they can count marked and unmarked packets to estimate the congestion 311 levels along the path. 313 However, the IESG has chartered the ConEx working group to establish 314 that there is sufficient demand for an IPv6 ConEx protocol before 315 using the last available bit in the IPv4 header. Furthermore this 316 encoding, by itself, does not sufficiently support partial deployment 317 or strong auditing and might motivate users and/or applications to 318 misrepresent the congestion that they are causing. 320 Nonetheless, this strawman encoding does present a clear mental model 321 of how the ConEx protocol might function under various uses. 323 3.2. ECN Based Encoding 325 Ideally ConEx and ECN are orthogonal signals and SHOULD be entirely 326 independent. However, given the limited number of header bit and/or 327 code points, these signals may have to share code points, at least 328 partially. 330 The re-ECN specification [I-D.briscoe-tsvwg-re-ecn-tcp] presents an 331 implementation of ConEx that is tightly integrated with the encoding 332 of ECN in the IP header. The central theme of this work is an audit 333 mechanism that can provide sufficient disincentives against 334 misrepresenting congestion [I-D.briscoe-tsvwg-re-ecn-motiv], which is 335 analyzed extensively in Briscoe's PhD dissertation [Refb-dis]. 337 Re-ECN is a good example of one chosen set of compromises attempting 338 to meet the requirements of Section 2. However, the present document 339 takes a step back, aiming to state the ideal requirements in order to 340 allow the Internet community to assess whether other compromises are 341 possible. 343 In particular, different incremental deployment choices may be 344 desirable to meet the partial deployment requirement of Section 2. 345 Re-ECN requires the receiver to be at least ECN-capable as well as 346 requiring an update to the sender. Although ConEx will inherently 347 require change at the sender, it would be preferable if it could 348 work, even partially, with any receiver. 350 The chosen ConEx protocol certainly must not require ECN to be 351 deployed in any network. In this respect re-ECN is already a good 352 example--it acts perfectly well as a loss-based ConEx protocol it the 353 loss-based audit techniques in Section 4.3 are used. However, it 354 would still be desirable to avoid the dependence on an ECN receiver. 356 For a tutorial background on Re-Feedback techniques, see [Re-fb, 357 FairerFaster]. 359 3.2.1. ECN Changes 361 Although the re-ECN protocol requires no changes to the network side 362 of the ECN protocol, it is important to note that it does propose 363 some relatively minor modifications to the host-to-host aspects of 364 the ECN protocol specified in RFC 3168. They include: redefining the 365 ECT(1) code point (the change is consistent with RFC3168 but requires 366 deprecating the experimental ECN nonce [RFC3540]); modifications to 367 the ECN negotiations carried on the SYN and SYN-ACK; and using a 368 different state machine to carry ECN signals in the transport 369 acknowledgments from the Receiver to the Sender. This last change 370 permits the transport protocol to carry multiple congestion signals 371 per round trip, and greatly simplifies accurate auditing. 373 All of these adjustments to RFC 3168 may also be needed in a future 374 standardized ConEx protocol. There will need to be very careful 375 consideration of any proposed changes to ECN or other existing 376 protocols, because any such changes increase the cost of deployment. 378 3.3. Abstract Encoding 380 The ConEx protocol could take one of two different encodings: 381 independently settable bits or an enumerated set of mutually 382 exclusive codepoints. 384 In both cases, the amount of congestion is signaled by the volume of 385 marked data--just as the volume of lost data or ECN marked data 386 signals the amount of congestion experienced. Thus the size of each 387 packet carrying a ConEx Signal is significant. 389 3.3.1. Independent Bits 391 This encoding involves flag bits, each of which the sender can set 392 independently to indicate to the network one of the following four 393 signals: 395 ConEx (Not-ConEx) The transport is (or is not) using ConEx with this 396 packet (the protocol MUST be arranged so that legacy transport 397 senders implicitly send Not-ConEx) 399 Re-Echo-Loss (Not-Re-Echo-Loss) The transport has (or has not) 400 experienced a loss 402 Re-Echo-ECN (Not-Re-Echo-ECN) The transport has (or has not) 403 experienced ECN signaled congestion 405 Credit (Not-Credit) The transport is (or is not) building up 406 congestion credit (see Section 4.3 on audit devices) 408 3.3.2. Codepoint Encoding 410 This encoding involves signaling one of the following five 411 codepoints: 413 ENUM {Not-ConEx, ConEx, Re-Echo-Loss, Re-Echo-ECN, Credit} 415 Each named codepoint has the same meaning as in the encoding using 416 independent bits (Section 3.3.1). The use of any one codepoint 417 implies the negative of all the others, except the last three 418 codepoints (Re-Echo-Loss, Re-Echo-ECN and Credit) obviously also 419 imply ConEx is supported. 421 Inherently, the semantics of most of the enumerated codepoints are 422 mutually exclusive. 'Credit' is the only one that might need to be 423 used in combination with either Re-Echo-Loss or Re-Echo-ECN, but even 424 that requirement is questionable. It must not be forgotten that the 425 enumerated encoding loses the flexibility to signal these two 426 combinations, whereas the encoding with four independent bits is not 427 so limited. Alternatively two extra codepoints could be assigned to 428 these two combinations of semantics. 430 4. Congestion Exposure Components 432 {ToDo: Picture of the components, similar to that in the last 433 slideset about conex-concepts-uses?} 435 4.1. Modified Senders 437 The sending transport needs to be modified to send Congestion 438 Exposure Signals in response to congestion feedback signals. 440 4.2. Receivers (Optionally Modified) 442 The receiving transport may already feedback sufficiently useful 443 signals to the sender so that it does not need to be altered. 445 However, a TCP receiver feeds back ECN congestion signals no more 446 than once within a round trip. The sender may require more precise 447 feedback from the receiver otherwise it will appear to be 448 understating its ConEx Signals (see Section 3.2.1). 450 Ideally, ConEx should be added to a transport like TCP without 451 mandatory modifications to the receiver. But an optional 452 modification to the receiver could be recommended for precision. 453 This was the approach taken when adding re-ECN to TCP 454 [I-D.briscoe-tsvwg-re-ecn-tcp]. 456 4.3. Audit 458 To audit ConEx Signals against actual losses an auditor could use one 459 of the following techniques: 461 TCP-specific approach: The auditor could monitor TCP flows or 462 aggregates of flows, only holding state on a flow if it first 463 sends a Credit or a Re-Echo-Loss marking. The auditor could 464 detect retransmissions by monitoring sequence numbers. It would 465 assure that (volume of retransmitted data) <= (volume of data 466 marked Re-Echo-Loss). Traffic would only be auditable in this way 467 if it conformed to the standard TCP protocol and the IP payload 468 was not encrypted (e.g. with IPsec). 470 Predominant bottleneck approach: Unlike the above TCP-specific 471 solution, this technique would work for IP packets carrying any 472 transport layer protocol, and whether encrypted or not. But it 473 only works well for networks designed so that losses predominantly 474 occur under the management of one IP-aware node on the path. The 475 auditor could then be located at this bottleneck. It could simply 476 compare ConEx Signals with actual local losses. Most consumer 477 access networks are design to this model, e.g. the radio network 478 controller (RNC) in a cellular network or the broadband remote 479 access server (BRAS) in a digital subscriber line (DSL) network. 481 The accuracy of an auditor at one predominant bottleneck might 482 still be sufficient, even if losses occasionally occurred at other 483 nodes in the network (e.g. border gateways). Although the auditor 484 at the predominant bottleneck would not always be able to detect 485 losses at other nodes, transports would not know where losses were 486 occurring either. Therefore any transport would not know which 487 losses it could cheat on without getting caught, and which ones it 488 couldn't. 490 To audit ConEx Signals against actual ECN markings or losses, the 491 auditor could work as follows: monitor flows or aggregates of flows, 492 only holding state on a flow if it first sends a Credit or either Re- 493 Echo marking. Count the number of bytes marked with Credit or Re- 494 Echo-ECN. Separately count the number of bytes marked with ECN. Use 495 Credits to assure that #ECN<=#Re-Echo-ECN+#Credit, even though the 496 Re-Echo-ECN markings are delayed by at least one RTT. 498 4.4. Policy Devices 500 Policy devices are characterised by a need to be configured with a 501 policy related to the users or neighboring networks being served. In 502 contrast, the auditing devices referred to in the previous section 503 primarily enforce compliance with the ConEx protocol and do not need 504 to be configured with any client-specific policy. 506 4.4.1. Congestion Policers 508 Note that a congestion policer can be implemented in a very similar 509 way to a bit-rate policer, but its effect is focused solely on 510 traffic causing congestion downstream, not on all traffic just in 511 case it causes congestion. 513 It monitors all ConEx traffic entering a network, or some 514 identifiable subset. Using ConEx signals, it measures the amount of 515 congestion being caused by this traffic. If this exceeds a policy- 516 configured 'congestion-bit-rate' the congestion policer will limit 517 all the monitored ConEx traffic. A congestion policer can be 518 implemented by a simple token bucket. But unlike a bit-rate policer, 519 it only removes tokens when forwarding packets that a ConEx marked. 520 See [CongPol] for details. 522 4.4.2. Other Policy Devices 524 Other policy devices that use ConEx signaling might traffic traffic 525 based on ConEx Signals in much the same way as the monitoring element 526 of a Congestion Policer. But the resulting action could be 527 different. It might re-route traffic or downgrade the class of 528 service. 530 It might do nothing directly to the traffic, but instead report 531 measurements of ConEx Signals to systems designed to control 532 congestion indirectly. For instance the measurements might be used 533 to trigger penalty clauses in contracts, to levy charges between 534 networks based on congestion or simply to notify customers who cause 535 excessive congestion. 537 an auditing device only needs to enforce protocol compliance, it does 538 not need to reflect any policy. 540 5. IANA Considerations 542 This memo includes no request to IANA. 544 Note to RFC Editor: this section may be removed on publication as an 545 RFC. 547 6. Security Considerations 549 Significant parts of this whole document are about the auditability 550 of ConEx Signals, in particular Section 4.3. 552 7. Conclusions 554 {ToDo:} 556 8. Acknowledgements 558 This document was improved by review comments from Toby Moncaster. 560 9. Comments Solicited 562 Comments and questions are encouraged and very welcome. They can be 563 addressed to the IETF Congestion Exposure (ConEx) working group 564 mailing list , and/or to the authors. 566 10. References 568 10.1. Normative References 570 [RFC2119] Bradner, S., "Key words for use in 571 RFCs to Indicate Requirement 572 Levels", BCP 14, RFC 2119, 573 March 1997. 575 10.2. Informative References 577 [CongPol] Jacquet, A., Briscoe, B., and T. 578 Moncaster, "Policing Freedom to Use 579 the Internet Resource Pool", Proc 580 ACM Workshop on Re-Architecting the 581 Internet (ReArch'08) , 582 December 2008, . 586 [FairerFaster] Briscoe, B., "A Fairer, Faster 587 Internet Protocol", IEEE 588 Spectrum Dec 2008:38--43, 589 December 2008, . 593 [I-D.briscoe-tsvwg-re-ecn-motiv] Briscoe, B., Jacquet, A., 594 Moncaster, T., and A. Smith, "Re- 595 ECN: A Framework for adding 596 Congestion Accountability to 597 TCP/IP", draft-briscoe-tsvwg-re- 598 ecn-tcp-motivation-01 (work in 599 progress), September 2009. 601 [I-D.briscoe-tsvwg-re-ecn-tcp] Briscoe, B., Jacquet, A., 602 Moncaster, T., and A. Smith, "Re- 603 ECN: Adding Accountability for 604 Causing Congestion to TCP/IP", 605 draft-briscoe-tsvwg-re-ecn-tcp-08 606 (work in progress), September 2009. 608 [I-D.conex-concepts-uses] Briscoe, B., Woundy, R., Moncaster, 609 T., and J. Leslie, "ConEx Concepts 610 and Use Cases", draft-moncaster- 611 conex-concepts-uses-01 (work in 612 progress), July 2010. 614 [I-D.ietf-ledbat-congestion] Shalunov, S. and G. Hazel, "Low 615 Extra Delay Background Transport 616 (LEDBAT)", 617 draft-ietf-ledbat-congestion-02 618 (work in progress), July 2010. 620 [I-D.sridharan-tcpm-ctcp] Sridharan, M., Tan, K., Bansal, D., 621 and D. Thaler, "Compound TCP: A New 622 TCP Congestion Control for High- 623 Speed and Long Distance Networks", 624 draft-sridharan-tcpm-ctcp-02 (work 625 in progress), November 2008. 627 [RFC0791] Postel, J., "Internet Protocol", 628 STD 5, RFC 791, September 1981. 630 [RFC2309] Braden, B., Clark, D., Crowcroft, 631 J., Davie, B., Deering, S., Estrin, 632 D., Floyd, S., Jacobson, V., 633 Minshall, G., Partridge, C., 634 Peterson, L., Ramakrishnan, K., 635 Shenker, S., Wroclawski, J., and L. 636 Zhang, "Recommendations on Queue 637 Management and Congestion Avoidance 638 in the Internet", RFC 2309, 639 April 1998. 641 [RFC3168] Ramakrishnan, K., Floyd, S., and D. 642 Black, "The Addition of Explicit 643 Congestion Notification (ECN) to 644 IP", RFC 3168, September 2001. 646 [RFC3514] Bellovin, S., "The Security Flag in 647 the IPv4 Header", RFC 3514, 648 April 2003. 650 [RFC3540] Spring, N., Wetherall, D., and D. 651 Ely, "Robust Explicit Congestion 652 Notification (ECN) Signaling with 653 Nonces", RFC 3540, June 2003. 655 [RFC3550] Schulzrinne, H., Casner, S., 656 Frederick, R., and V. Jacobson, 657 "RTP: A Transport Protocol for 658 Real-Time Applications", STD 64, 659 RFC 3550, July 2003. 661 [RFC5670] Eardley, P., "Metering and Marking 662 Behaviour of PCN-Nodes", RFC 5670, 663 November 2009. 665 [RFC5681] Allman, M., Paxson, V., and E. 666 Blanton, "TCP Congestion Control", 667 RFC 5681, September 2009. 669 [Re-fb] Briscoe, B., Jacquet, A., Di 670 Cairano-Gilfedder, C., Salvatori, 671 A., Soppera, A., and M. Koyabe, 672 "Policing Congestion Response in an 673 Internetwork Using Re-Feedback", 674 ACM SIGCOMM CCR 35(4)277--288, 675 August 2005, . 679 [Refb-dis] Briscoe, B., "Re-feedback: Freedom 680 with Accountability for Causing 681 Congestion in a Connectionless 682 Internetwork", UCL PhD 683 Dissertation , 2009, . 687 [Vegas] Brakmo, L. and L. Peterson, "TCP 688 Vegas: End-to-End Congestion 689 Avoidance on a Global Internet", 690 IEEE Journal on Selected Areas in 691 Communications 13(8)1465--80, 692 October 1995, . 696 Authors' Addresses 698 Matt Mathis 699 Google 701 Phone: 702 Fax: 703 EMail: mattmathis at google.com 704 URI: 706 Bob Briscoe 707 BT 708 B54/77, Adastral Park 709 Martlesham Heath 710 Ipswich IP5 3RE 711 UK 713 Phone: +44 1473 645196 714 EMail: bob.briscoe@bt.com 715 URI: http://bobbriscoe.net/