idnits 2.17.1 draft-ietf-conex-tcp-modifications-07.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 (February 14, 2015) is 3358 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'DCTCP' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'I-D.briscoe-tsvwg-re-ecn-tcp' is defined on line 573, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Congestion Exposure (ConEx) M. Kuehlewind, Ed. 3 Internet-Draft ETH Zurich 4 Intended status: Experimental R. Scheffenegger 5 Expires: August 18, 2015 NetApp, Inc. 6 February 14, 2015 8 TCP modifications for Congestion Exposure 9 draft-ietf-conex-tcp-modifications-07 11 Abstract 13 Congestion Exposure (ConEx) is a mechanism by which senders inform 14 the network about the congestion encountered by previous packets on 15 the same flow. This document describes the necessary modifications 16 to use ConEx with the Transmission Control Protocol (TCP). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 18, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Sender-side Modifications . . . . . . . . . . . . . . . . . . 3 55 3. Accounting congestion . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Loss Detection . . . . . . . . . . . . . . . . . . . . . 5 57 3.1.1. Without SACK Support . . . . . . . . . . . . . . . . 6 58 3.2. ECN . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.2.1. Accurate ECN feedback . . . . . . . . . . . . . . . . 8 60 3.2.2. Classic ECN support . . . . . . . . . . . . . . . . . 8 61 4. Setting the ConEx Bits . . . . . . . . . . . . . . . . . . . 9 62 4.1. Setting the E and the L Bit . . . . . . . . . . . . . . . 9 63 4.2. Credit Bits . . . . . . . . . . . . . . . . . . . . . . . 9 64 5. Loss of ConEx information . . . . . . . . . . . . . . . . . . 11 65 6. Timeliness of the ConEx Signals . . . . . . . . . . . . . . . 11 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 10.2. Informative References . . . . . . . . . . . . . . . . . 13 72 Appendix A. Revision history . . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction 77 Congestion Exposure (ConEx) is a mechanism by which senders inform 78 the network about the congestion encountered by previous packets on 79 the same flow. ConEx concepts and use cases are further explained in 80 [RFC6789]. The abstract ConEx mechanism is explained in 81 [draft-ietf-conex-abstract-mech]. This document describes the 82 necessary modifications to use ConEx with the Transmission Control 83 Protocol (TCP). 85 The needed markings to provide ConEx signaling are defined in the 86 ConEx Destination Option (CDO) for IPv6 [draft-ietf-conex-destopt]. 87 Specifically, the use of four bits are defined: the X (ConEx- 88 capable), the L (loss experienced), the E (ECN experienced) and C 89 (credit) bit. 91 ConEx signaling is based on loss or Explicit Congestion Notification 92 (ECN) marks [RFC3168] as a congestion indication. This congestion 93 information is retrieved by the sender based on existing feedback 94 mechanisms from the receiver to the sender in TCP. No changes are 95 needed at the receiver to implement ConEx signaling. Therefore no 96 additional negotiation is needed to implement and use ConEx at the 97 sender. This document specifies actions needed by sender to provide 98 meaningful ConEx information to the network. 100 Section 2 provides an overview of the needed modifications for TCP 101 senders to implement ConEx. First congestion information have to be 102 extracted from loss or ECN feedback in TCP as described in section 3. 103 Section 4 details how to set the CDO marking based on the accounted 104 congestion information. Section 6 finally discusses timeliness of 105 the ConEx feedback signal as congestion is a temporary state. 107 This document describes congestion accounting for both TCP with and 108 without the Selective Acknowledgment (SACK) extension [RFC2018] in 109 section 3.1. However, ConEx benefits from more accurate information 110 about the number of packets dropped in the network. It is therefore 111 recommended to use the SACK extension when using TCP with ConEx. The 112 detailed mechanism to respectively set the L bit in response to loss- 113 based congestion feedback signal is given in section 4.1. 115 While loss-based congestion feedback should be minimized, ECN could 116 actually provide more fine-grained feedback information. ConEx-based 117 traffic measurement or management mechanisms would benefit from this. 118 Unfortunately, the current ECN feedback mechanism does not reflect 119 multiple congestion markings which occur within the same Round-Trip 120 Time (RTT). A more accurate feedback extension to ECN is proposed in 121 a separate document [draft-kuehlewind-tcpm-accurate-ecn], as this is 122 also useful for other mechanisms. 124 The congestion accounting for both, with the classic ECN feedback as 125 well as a more accurate ECN feedback are explained in detail in 126 section 3.2 while the setting of the E bit in response to ECN-based 127 congestion feedback is again detailed in section 4.1. 129 1.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 2. Sender-side Modifications 137 This section gives an overview of actions that need to be taken by a 138 TCP sender that would like to use ConEx signaling. 140 A ConEx sender MUST negotiate for both SACK and ECN or the more 141 accurate ECN feedback in the TCP handshake if these TCP extension are 142 available at the sender. Therefore a ConEx sender SHOULD also 143 implement SACK and ECN. Depending on the capability of the receiver, 144 the following operation modes exist: 146 o SACK-accECN-ConEx (SACK and accurate ECN feedback) 148 o accECN-ConEx (no SACK but accurate ECN feedback) 150 o ECN-ConEx (no SACK and no accurate ECN feedback but 'classic' ECN) 152 o SACK-ECN-ConEx (SACK and 'classic' instead of accurate ECN) 154 o SACK-ConEx (SACK but no ECN at all) 156 o Basic-ConEx (neither SACK nor ECN) 158 A ConEx sender MUST expose all congestion information to the network 159 according to the congestion information received by ECN or based on 160 loss information provided by the TCP feedback loop. A TCP sender 161 SHOULD account congestion byte-wise (and not packet-wise). A sender 162 MUST mark subsequent packets (after the congestion notification) with 163 the respective ConEx bit in the IP header. Furthermore, a ConEx 164 sender must send enough credit to cover all experienced congestion 165 for the connection so far, as well as the risk of congestion for the 166 current transmission (see Section 4.2). 168 With SACK only the number of lost payload bytes is known, but not the 169 number of packets carrying these bytes. With classic ECN only an 170 indication is given that a marking occurred but not the exact number 171 of payload bytes nor packets. As network congestion is usually byte- 172 congestion [draft-briscoe-tsvwg-byte-pkt-mark], the exact number of 173 bytes should be taken into account, if available, to make the ConEx 174 signal as exact as possible. 176 Detailed mechanisms for congestion accounting in each operation mode 177 are described in the next section. Further handling of the IPv6 bits 178 itself if congestion was accounted is described in the subsequent 179 section afterwards. 181 3. Accounting congestion 183 A ConEx sender maintains two counters: one that accounts congestion 184 based on the information retrived by loss detection, and a second 185 that accounts for ECN based congestion feedback (in TCP). These 186 counters hold the number of outstanding bytes that should be ConEx 187 marked either with the E bit or the L bit in subsequent packets. 189 The outstanding bytes for congestion indications based on loss are 190 maintained in the loss exposure gauge (LEG) and the accounting is 191 explained in Section 3.1. 193 The outstanding bytes accounted based on ECN feedback information are 194 maintained in the congestion exposure gauge (CEG). The accounting of 195 these bytes from the ECN feedback is explained in more detail next in 196 Section 3.2. 198 Furthermore, those counters will be reduced every time a ConEx 199 capable packet with the E or L bit set is sent. This is explained 200 for both counters in Section 4.1. 202 Usually all bytes of an IP packet must be accounted. Therefore the 203 sender SHOULD take the headers into account, too. If equal sized 204 packets, or at least equally distributed packet sizes can be assumed, 205 the sender MAY only account the TCP payload bytes. In this case 206 there should be about the same number of ConEx marked packets as the 207 original packets that were causing the congestion. Thus both contain 208 about the same number of header bytes. This case is assumed for 209 simplification in the following sections. 211 Otherwise if this is not the case and a sender sends different sized 212 packets (with unequally distributed packet sizes), the sender needs 213 to memorize or estimate the number of ECN-marked or lost packets. A 214 sender might be able to reconstruct the number of packets and thus 215 the header bytes if the packet sizes of all packets that were sent 216 during the last RTT are known. Otherwise if no additional 217 information is available the worst case number of packets and thus 218 header bytes should be estimated in a conservative way based on a 219 minimum packet size (of all packets sent in the last RTT). If the 220 number of ConEx marked packets is smaller (or larger) than the 221 estimated number of ECN-marked or lost packets, the additional header 222 bytes should the added to (or can be subtracted from) the respective 223 counter. 225 3.1. Loss Detection 227 A ConEx sender MUST maintain a loss exposure gauge (LEG), indicating 228 the number of outstanding bytes that must be sent with the ConEx L 229 bit. When a data segment is retransmitted, LEG will be increased by 230 the size of the TCP payload bytes contained by the retransmission, 231 assuming equal sized segments such that the retransmitted packet will 232 have the same number of header bytes as the original ones. 234 Any retransmission may be spurious. To accommodate that, a ConEx 235 sender SHOULD make use of heuristics to detect such spurious 236 retransmissions (e.g. F-RTO [RFC5682], DSACK [RFC3708], and Eifel 237 [RFC3522], [RFC4015]). When such a heuristic has determined, that a 238 certain number of packets were retransmitted erroneously, the ConEx 239 sender should subtract the payload size of these TCP packets from 240 LEG. 242 3.1.1. Without SACK Support 244 If multiple losses occur within one RTT and SACK is not used, it may 245 take several RTTs until all lost data is retransmitted. With the 246 scheme described above, the ConEx information will be delayed 247 strongly but timeliness is important for ConEx. 249 For ConEx it is not important to know which data got lost but only 250 how much. During the first RTT after the initial loss detection, the 251 amount of received data and thus also the amount of lost data can be 252 estimated based on the number of received ACKs. Thus without SACK, 253 the needed information for the ConEx feedback can be available with 254 an additionally delay of one RTT by using the following estimation 255 algorithm and an additional Loss Estimation Counter (LEC): 257 flight_bytes: current flight size in bytes 258 retransmit_bytes: payload size of the retransmission 260 At the first retransmission in a congestion event LEC is set: 262 LEC = flight_bytes - 3*SMSS 264 (At this point of time in the transmission, in the worst case, 265 all packets in flight minus three that trigged the dupACks 266 could have been lost.) 268 Then during the first RTT of the congestion event: 270 For each retransmission: 271 LEG += retransmit_bytes 272 LEC -= retransmit_bytes 274 For each ACK: 275 LEC -= SMSS 277 After one RTT: 279 LEG += LEC 281 (The LEC now estimates the number of outstanding bytes 282 that should be ConEx L marked.) 284 After the first RTT for each following retransmissions: 286 if (LEC > 0): LEC -= retransmit_bytes 287 else if (LEC==0): LEG += retransmit_bytes 289 if (LEC < 0): LEG += -LEC 291 (The LEG is not increased for those bytes that were 292 already accounted.) 294 3.2. ECN 296 ECN [RFC3168] is an IP/TCP mechanism that allows network nodes to 297 mark packets with the Congestion Experienced (CE) mark instead of 298 (early) dropping them when congestion occurs. As soon as a CE mark 299 is seen at the receiver, with classic ECN it will feed this 300 information back to the sender by setting the Echo Congestion 301 Experienced (ECE) bit in the TCP header of all subsequent ACKs until 302 a packet with Congestion Window Reduced (CWR) bit in the TCP header 303 is received to acknowledge the reception of the congestion 304 notification. The sender sets the CWR bit in the TCP header once 305 when the first ECE of a congestion notification is received. 307 A receiver can support 'classic' ECN, a more accurate ECN feedback 308 scheme, or neither. In the case ECN is not supported at all, of 309 course, no ECN marks will occur, thus the E bit will never be set. 310 Otherwise, a ConEx sender must maintain a counter, the congestion 311 exposure gauge (CEG), for the number of outstanding bytes that have 312 to be ConEx marked with the E bit. 314 The CEG is increased when ECN information is received from an ECN- 315 capable receiver supporting the 'classic' ECN scheme or the accurate 316 ECN feedback scheme. When the ConEx sender receives an ACK 317 indicating one or more segments were received with a CE mark, CEG is 318 increased by the appropriate number of bytes as described further 319 below. 321 Unfortunately in case of duplicate acknowledgements the number of 322 newly acknowledged bytes will be zero even though (CE marked) data 323 has been received. Therefore, we increase the CEG by DeliveredData, 324 as defined below: 326 DeliveredData = acked_bytes + SACK_diff + (is_dup)*1SMSS - 327 (is_after_dup)*num_dup*1SMSS 329 DeliveredData covers the number of bytes which has been newly 330 delivered to the receiver. Therefore on each arrival of an ACK, 331 DeliveredData will be increased by the newly acknowledged bytes 332 (acked_bytes) as indicated by the current ACK, relative to all past 333 ACKs. 335 Moreover with SACK, DeliveredData is increased by the number of bytes 336 provided by (new) SACK information (SACK_diff). Note, if less 337 unacknowledged bytes are announced in the new SACK information than 338 in the previous ACK, SACK_diff can be negative. In this case, data 339 is newly acknowledged (in acked_byte), that has previously already 340 been accounted to DeliveredData based on SACK information. 342 Without SACK, DeliveredData is estimated to be 1 SMSS on duplicate 343 acknowledgements. For the subsequent partial or full ACK, 344 DeliveredData is estimated to be the newly acknowledged bytes, minus 345 one SMSS for each preceding duplicate ACK. Therefore is_dup is one 346 if the current ACK is a duplicated ACK without SACK, and zero 347 otherwise. is_after_dup is only one for the next full or partial ACK 348 after a number of duplicated ACKs without SACK and num_dup counts the 349 number of duplicated ACKs in a row. 351 The two cases, with and without more accurate ECN depending on the 352 receiver capability, are discussed in the following sections. 354 3.2.1. Accurate ECN feedback 356 With a more accurate ECN feedback scheme either the number of marked 357 packets/received CE marks or directly the number of marked bytes is 358 known. In the later case the CEG can directly be increased by the 359 number of marked bytes. Otherwise if D is assumed to be the number 360 of marks, the gauge CEG will be conservatively increased by one SMSS 361 for each marking or at max the number of newly acknowledged bytes: 363 CEG += min(SMSS*D, DeliveredData) 365 3.2.2. Classic ECN support 367 If the ConEx sender fully conforms to the semantics of the ECN 368 signaling as defined by [RFC5562], it will receive one full RTT of 369 ACKs with the ECE flag set whenever at least one CE mark was received 370 by the receiver. As the sender cannot estimate how much packets have 371 actually been CE marked during this RTT, the most conservative 372 assumption should be taken, namely assuming that all packets were 373 marked. This can be achieved by increasing the CEG by DeliveredData 374 for each ACK with the ECE flag: 376 CEG += DeliveredData 378 Optionally a ConEx sender could implement an Advanced Compatibility 379 Mode: 381 To extract more than one ECE indication per RTT, a ConEx sender could 382 set the CWR flag opportunistically to force the receiver to signal 383 only one ECE per CE mark. Unfortunately, the use of delayed ACKs 384 [RFC5681], as it is usually done today, will prevent a feedback of 385 every CE mark. If an CWR confirmation will be received before the 386 ECE can be sent out with the next ACK, ECN feedback information 387 information could get lost. Thus a sender should set CWR only on 388 those data segments, that will actually trigger a (delayed) ACK. The 389 sender would need an additional control loop to estimated which data 390 segment will trigger an ACK. But such a more sophisticated 391 heuristics could extract congestion notifications more timely. Still 392 the CEG need to be increased by DeliveredData, as one or more CE 393 marked packets could be acknowledged by one delayed ACK. 395 4. Setting the ConEx Bits 397 By setting the X bit a packet is marked as ConEx-capable. All 398 packets carrying payload MUST be marked with the X bit set including 399 retransmissions. No congestion feedback information are available 400 about control packets such as pure ACKs which are not carrying any 401 payload. Thus these packets should not be taken into account when 402 determining ConEx information. These packet MUST carry a ConEx 403 Destination Option with the X bit unset. 405 4.1. Setting the E and the L Bit 407 As long as the CEG or LEG counter is positive, ConEx-capable packets 408 SHOULD be marked with E or L respectively, and the CEG or LEG counter 409 is decreased by the TCP payload bytes carried in this packet. If the 410 CEG or LEG counter is negative, the respective counter SHOULD be 411 reset to zero within one RTT after it was decreased the last time or 412 one RTT after recovery if no further congestion occurred. 414 If SACK information is not available spurious retransmission are more 415 likely. In this case it might be valuable to slightly delay the 416 ConEx loss feedback until a spurious retransmission might be 417 detected. But the ConEx signal MUST NOT be delayed more than one RTT 418 if as long as data packets are sent out. 420 4.2. Credit Bits 422 The ConEx abstract mechanism requires that sufficient credit must be 423 signaled in advance to cover the expected congestion during the 424 feedback delay of one RTT. A ConEx sender should maintain a counter 425 of the sent credits c in bytes. If congestion occurs, credits will 426 be consumed and the c counter should be reduced by the number of 427 bytes that where lost or estimated to be ECN-marked. If the risk of 428 congestion was estimated wrongly and thus too few credits were sent, 429 the c counter becomes zero but can not get negative. 431 The number of credits sent should always equal the number of bytes in 432 flight, as all packets could potentially get lost or congestion 433 marked. Thus a ConEx sender should monitor the number of bytes in 434 flight f. If f ever becomes larger than c, the ConEx sender SHOULD 435 send new credits. Remember that c will be decreased if congestion 436 occurs. 438 In TCP Slow Start, the congestion window might grow much larger than 439 during the rest of the transmission. Thus a sender could consider to 440 sent fewer than f credits but risking potential penalization by an 441 audit. In any case the credits should at least cover the increase in 442 sending rate. As the sending rate increases exponentially in Slow 443 Start, thus double every RTT, a ConEx sender should at least cover 444 half the number of packets in flight by credits. Note, that the 445 number of losses or markings within one RTT does not only depend 446 actions taken by the sender. In general, the behavior of the cross 447 traffic, and if Active Queue Management (AQM) is used, the respective 448 parameterization influence how many packets get dropped or marked. 449 But if the used AQM is not overly aggressive with ECN marking, 450 sending halve the flight size as credits should be sufficient for 451 both, congestion signaled by loss or ECN. Marking every fourth 452 packet will allow the respective number of credits in Slow Start as 453 it can be seen in Figure Figure 1. 455 RTT1 |------XC------>| 456 |------X------->| 457 |------X------->| credit=1 in_flight=3 458 | | 459 RTT2 |------X------->| 460 |------XC------>| 461 |------X------->| 462 |------X------->| 463 |------X------->| 464 |------XC------>| credit=3 in_flight=6 465 | | 466 RTT3 |------X------->| 467 |------X------->| 468 |------X------->| 469 |------XC------>| 470 |------X------->| 471 |------X------->| 472 |------X------->| 473 |------XC------>| 474 |------X------->| 475 |------X------->| 476 |------X------->| 477 |------XC------>| credit=6 in_flight=12 478 | . | 479 | : | 481 Figure 1: Credits in Slow Start (with an initial window of 3) 483 It is possible that the audit looses state due to e.g. rerouting or 484 memory limitations. Therefore, the sender needs to detect this case 485 and resend credits. Thus a ConEx sender should reset the credit 486 count c to zero if losses occur in two subsequent RTTs (assuming that 487 the sending rate was correctly reduced based on the received 488 congestion signal). 490 5. Loss of ConEx information 492 Packets carrying ConEx can also get lost. A ConEx sender must 493 remember which packet was marked with either the L, the E or the C 494 bit. If one of these packets is detected to be lost, the should 495 increase the respective gauge, LEG or CEG, by the number of lost 496 payload bytes. 498 6. Timeliness of the ConEx Signals 500 ConEx signals can only be evaluated by a network node with a time 501 delay of about one RTT after the congestion occured. To avoid 502 further delays, a ConEx sender SHOULD sent the ConEx signaling with 503 the next available packet. In cases where it is preferable to 504 slightly delay the ConEx signal, the sender MUST NOT delay the ConEx 505 signal more than one RTT. 507 Multiple ConEx bits may become available for signaling at the same 508 time, for example when an ACK is received by the sender, that 509 indicates at the same time that at least one segment has been lost, 510 and that one or more ECN marks were received. This may happen during 511 excessive congestion, where the queues overflow even though ECN was 512 used and currently all packets are marked, while others have to be 513 dropped nevertheless. Another possibility when this may happen are 514 lost ACKs, so that a subsequent ACK carries summary information not 515 previously available to the sender. As ConEx-capable packet can 516 carry different ConEx marks at the same time, these information do 517 not need to be distributed over several packets and thus can be sent 518 without further delay. 520 7. Acknowledgements 522 The authors would like to thank Bob Briscoe who contributed with this 523 initial ideas and valuable feedback. Moreover, thanks to Jana 524 Iyengar who provided valuable feedback. 526 8. IANA Considerations 528 This document does not have any requests to IANA. 530 9. Security Considerations 532 With some of the advanced ECN compatibility modes it is possible to 533 miss congestion notifications. Thus a sender will not decrease its 534 sending rate. If the congestion is persistent, the likelihood to 535 receive a congestion notification increases. In the worst case the 536 sender will still react correctly to loss. This will prevent a 537 congestion collapse. 539 10. References 541 10.1. Normative References 543 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 544 Selective Acknowledgment Options", RFC 2018, October 1996. 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, March 1997. 549 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 550 of Explicit Congestion Notification (ECN) to IP", RFC 551 3168, September 2001. 553 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 554 Control", RFC 5681, September 2009. 556 [draft-ietf-conex-abstract-mech] 557 Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 558 Concepts and Abstract Mechanism", draft-ietf-conex- 559 abstract-mech-06 (work in progress), October 2012. 561 [draft-ietf-conex-destopt] 562 Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6 563 Destination Option for ConEx", draft-ietf-conex-destopt-04 564 (work in progress), March 2013. 566 10.2. Informative References 568 [DCTCP] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, 569 P., Prabhakar, B., Sengupta, S., and M. Sridharan, "DCTCP: 570 Efficient Packet Transport for the Commoditized Data 571 Center", Jan 2010. 573 [I-D.briscoe-tsvwg-re-ecn-tcp] 574 Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith, 575 "Re-ECN: Adding Accountability for Causing Congestion to 576 TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-09 (work in 577 progress), October 2010. 579 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 580 for TCP", RFC 3522, April 2003. 582 [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective 583 Acknowledgement (DSACKs) and Stream Control Transmission 584 Protocol (SCTP) Duplicate Transmission Sequence Numbers 585 (TSNs) to Detect Spurious Retransmissions", RFC 3708, 586 February 2004. 588 [RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm 589 for TCP", RFC 4015, February 2005. 591 [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. 592 Ramakrishnan, "Adding Explicit Congestion Notification 593 (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, June 594 2009. 596 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 597 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 598 Spurious Retransmission Timeouts with TCP", RFC 5682, 599 September 2009. 601 [RFC6789] Briscoe, B., Woundy, R., and A. Cooper, "Congestion 602 Exposure (ConEx) Concepts and Use Cases", RFC 6789, 603 December 2012. 605 [draft-briscoe-tsvwg-byte-pkt-mark] 606 Briscoe, B. and J. Manner, "Byte and Packet Congestion 607 Notification", draft-briscoe-tsvwg-byte-pkt-mark-010 (work 608 in progress), May 2013. 610 [draft-kuehlewind-tcpm-accurate-ecn] 611 Kuehlewind, M. and R. Scheffenegger, "More Accurate ECN 612 Feedback in TCP", draft-kuehlewind-tcpm-accurate-ecn-02 613 (work in progress), Jun 2013. 615 Appendix A. Revision history 617 RFC Editior: This section is to be removed before RFC publication. 619 00 ... initial draft, early submission to meet deadline. 621 01 ... refined draft, updated LEG "drain" from per-packet to RTT- 622 based. 624 02 ... added Section 5 and expanded discussion about ECN interaction. 626 03 ... expanded the discussion around credit bits. 628 04 ... review comments of Jana addressed. (Change in full compliance 629 mode.) 631 05 ... changes on Loss Detection without SACK, support of classic ECN 632 and credit handling. 634 Authors' Addresses 636 Mirja Kuehlewind (editor) 637 ETH Zurich 638 Switzerland 640 Email: mirja.kuehlewind@tik.ee.ethz.ch 642 Richard Scheffenegger 643 NetApp, Inc. 644 Am Euro Platz 2 645 Vienna 1120 646 Austria 648 Phone: +43 1 3676811 3146 649 Email: rs@netapp.com