idnits 2.17.1 draft-ietf-conex-tcp-modifications-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 (February 14, 2014) is 3716 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'DCTCP' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'I-D.briscoe-tsvwg-re-ecn-tcp' is defined on line 530, 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 University of Stuttgart 4 Intended status: Experimental R. Scheffenegger 5 Expires: August 18, 2014 NetApp, Inc. 6 February 14, 2014 8 TCP modifications for Congestion Exposure 9 draft-ietf-conex-tcp-modifications-05 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, 2014. 35 Copyright Notice 37 Copyright (c) 2014 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. ECN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1.1. Accurate ECN feedback . . . . . . . . . . . . . . . . 6 58 3.1.2. Classic ECN support . . . . . . . . . . . . . . . . . 6 59 3.2. Loss Detection . . . . . . . . . . . . . . . . . . . . . 7 60 3.2.1. Without SACK Support . . . . . . . . . . . . . . . . 7 61 4. Setting the ConEx Bits . . . . . . . . . . . . . . . . . . . 8 62 4.1. Setting the E and the L Bit . . . . . . . . . . . . . . . 8 63 4.2. Credit Bits . . . . . . . . . . . . . . . . . . . . . . . 8 64 5. Loss of ConEx information . . . . . . . . . . . . . . . . . . 10 65 6. Timeliness of the ConEx Signals . . . . . . . . . . . . . . . 10 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 10.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Appendix A. Revision history . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 ConEx signal is based on loss or Explicit Congestion Notification 86 (ECN) marks [RFC3168] as a congestion indication. This congestion 87 information is retrieved by the sender based on existing feedback 88 mechanisms from the receiver to the sender in TCP. 90 This document describes mechanisms for both TCP with and without the 91 Selective Acknowledgment (SACK) extension [RFC2018]. However, ConEx 92 benefits from more accurate information about the number of packets 93 dropped in the network. We therefore recommend using the SACK 94 extension when using TCP with ConEx. 96 While loss-based congestion feedback should be minimized, ECN could 97 actually provide more fine-grained feedback information. ConEx-based 98 traffic measurement or management mechanism would benefit from this. 99 Unfortunately the current ECN does not reflect multiple congestion 100 markings which occur within the same Round-Trip Time (RTT). A more 101 accurate feedback extension to ECN is defined in a separate document 102 [draft-kuehlewind-tcpm-accurate-ecn], as this is also useful for 103 other mechanisms. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 2. Sender-side Modifications 113 A ConEx sender MUST negotiate for both SACK and ECN or the more 114 accurate ECN feedback in the TCP handshake if these TCP extension are 115 available at the sender. Thus a ConEx SHOULD also implement SACK and 116 ECN. Depending on the capability of the receiver, the following 117 operation modes exist: 119 o SACK-accECN-ConEx (SACK and accurate ECN feedback) 121 o accECN-ConEx (no SACK but accurate ECN feedback) 123 o ECN-ConEx (no SACK and no accurate ECN feedback but 'classic' ECN) 125 o SACK-ECN-ConEx (SACK and 'classic' instead of accurate ECN) 127 o SACK-ConEx (SACK but no ECN at all) 129 o Basic-ConEx (neither SACK nor ECN) 131 A ConEx sender MUST expose all congestion information to the network 132 according to the congestion information received by ECN or based on 133 loss information provided by the TCP feedback loop. A TCP sender 134 SHOULD account congestion byte-wise (and not packet-wise). A sender 135 MUST mark subsequent packets (after the congestion notification) with 136 the respective ConEx bit in the IP header. Furthermore, a ConEx 137 sender must send enough credit to cover all experienced congestion 138 for the connection so far, as well as the risk of congestion for the 139 current transmission (see Section 4.2. 141 With SACK only the number of lost payload bytes is known, but not the 142 number of packets carrying these bytes. With classic ECN only an 143 indication is given that a marking occurred but not the exact number 144 of payload bytes nor packets. As network congestion is usually byte- 145 congestion [draft-briscoe-tsvwg-byte-pkt-mark], the exact number of 146 bytes should be taken into account, if available, to make the ConEx 147 signal as exact as possible. 149 The congestion accounting for each operation mode is described in the 150 next section and the handling of the IPv6 bits itself in the 151 subsequent section afterwards. 153 3. Accounting congestion 155 A ConEx sender, thats accounts congestion byte-wise based on the 156 congestion information received by ECN or loss detection provided by 157 TCP, will maintain two different counters. These counters hold the 158 number of outstanding bytes that should be ConEx marked either with 159 the E bit or the L bit in subsequent packets. 161 The outstanding bytes accounted based on ECN feedback information are 162 maintained in the congestion exposure gauge (CEG). The accounting of 163 these bytes from the ECN feedback is explained in more detail next in 164 Section 3.1. 166 The outstanding bytes for congestion indications based on loss are 167 maintained in the loss exposure gauge (LEG) and the accounting is 168 explained in Section 3.2. 170 Furthermore, those counters will be reduced every time a ConEx 171 capable packet with the E or L bit set is sent. This is explained 172 for both counters in Section 4.1. 174 Usually all bytes of an IP packet must be accounted. Therefore the 175 sender SHOULD take the headers into account, too. If equal sized 176 packets, or at least equally distributed packet sizes can be assumed, 177 the sender MAY only account the TCP payload bytes. In this case 178 there should be about the same number of ConEx marked packets as the 179 original packets that were causing the congestion. Thus both contain 180 about the same number of header bytes. This case is assumed for 181 simplification in the following sections. 183 Otherwise if this is not the case and a sender sends different sized 184 packets (with unequally distributed packet sizes), the sender needs 185 to memorize or estimate the number of ECN-marked or lost packets. A 186 sender might be able to reconstruct the number of packets and thus 187 the header bytes if the packet sizes of all packets that were sent 188 during the last RTT are known. Otherwise if no additional 189 information is available the worst case number of packets and thus 190 header bytes should be estimated in a conservative way based on a 191 minimum packet size (of all packets sent in the last RTT). If the 192 number of ConEx marked packets is smaller (or larger) than the 193 estimated number of ECN-marked or lost packets, the additional header 194 bytes should the added to (or can be subtracted from) the respective 195 counter. 197 3.1. ECN 199 ECN [RFC3168] is an IP/TCP mechanism that allows network nodes to 200 mark packets with the Congestion Experienced (CE) mark instead of 201 (early) dropping them when congestion occurs. As soon as a CE mark 202 is seen at the receiver, with classic ECN it will feed this 203 information back to the sender by setting the Echo Congestion 204 Experienced (ECE) bit in the TCP header of all subsequent ACKs until 205 a packet with Congestion Window Reduced (CWR) bit in the TCP header 206 is received to acknowledge the reception of the congestion 207 notification. The sender sets the CWR bit in the TCP header once 208 when the first ECE of a congestion notification is received. 210 A receiver can support 'classic' ECN, a more accurate ECN feedback 211 scheme, or neither. In the case ECN is not supported at all, of 212 course, no ECN marks will occur, thus the E bit will never be set. 213 Otherwise, a ConEx sender must maintain a counter, the congestion 214 exposure gauge (CEG), for the number of outstanding bytes that have 215 to be ConEx marked with the E bit. 217 The CEG is increased when ECN information is received from an ECN- 218 capable receiver supporting the 'classic' ECN scheme or the accurate 219 ECN feedback scheme. When the ConEx sender receives an ACK 220 indicating one or more segments were received with a CE mark, CEG is 221 increased by the appropriate number of bytes as described further 222 below. 224 Unfortunately in case of duplicate acknowledgements the number of 225 newly acknowledged bytes will be zero even though (CE marked) data 226 has been received. Therefore, we increase the CEG by DeliveredData, 227 as defined below: 229 DeliveredData covers the number of bytes which has been newly 230 delivered to the receiver. Therefore on each arrival of an ACK, 231 DeliveredData will be calculated by the newly acknowledged bytes 232 (acked_bytes) as indicated by the current ACK, relative to all past 233 ACKs. Moreover with SACK, DeliveredData is increased by the number 234 of bytes provided by (new) SACK information (SACK_diff). Note, if 235 less unacknowledged bytes are announced in the new SACK information 236 than in the previous ACK, SACK_diff can be negative. In this case, 237 data is newly acknowledged (in acked_byte), that has previously 238 already been accounted to DeliveredData based on SACK information. 239 Without SACK, DeliveredData is estimated to be 1 SMSS on duplicate 240 acknowledgements. For the subsequent partial or full ACK, 241 DeliveredData is estimated to be the newly acknowledged bytes, minus 242 one SMSS for each preceding duplicate ACK. 244 DeliveredData = acked_bytes + SACK_diff + (is_dup)*1SMSS - 245 (is_after_dup)*num_dup*1SMSS 247 Thus is_dup is one if the current ACK is a duplicated ACK without 248 SACK, and zero otherwise. is_after_dup is only one for the next full 249 or partial ACK after a number of duplicated ACKs without SACK and 250 num_dup counts the number of duplicated ACKs in a row. 252 The two cases, with and without more accurate ECN depending on the 253 receiver capability, are discussed in the following sections. 255 3.1.1. Accurate ECN feedback 257 With a more accurate ECN feedback scheme either the number of marked 258 packets/received CE marks or directly the number of marked bytes is 259 known. In the later case the CEG can directly be increased by the 260 number of marked bytes. Otherwise if D is assumed to be the number 261 of marks, the gauge CEG will be conservatively increased by one SMSS 262 for each marking or at max the number of newly acknowledged bytes: 264 CEG += min(SMSS*D, DeliveredData) 266 3.1.2. Classic ECN support 268 If the ConEx sender fully conforms to the semantics of the ECN 269 signaling as defined by [RFC5562], it will receive one full RTT of 270 delayed ACKs with the ECE flag set whenever at least one CE mark was 271 received by the receiver. As the sender cannot estimate how much 272 packets have actually been CE marked during this RTT, the most 273 conservative assumption should be taken, namely assuming that all 274 packets were marked. This can be achieved by increasing the CEG by 275 DeliveredData for each ACK with the ECE flag: 277 CEG += DeliveredData 279 Optionally a ConEx sender could implement an Advanced Compatibility 280 Mode: 282 To extract more than one ECE indication per RTT, a ConEx sender could 283 set the CWR flag opportunistically to force the receiver to signal 284 only one ECE per CE mark. Unfortunately, the use of delayed ACKs 285 [RFC5681], as it is usually done today, will prevent a feedback of 286 every CE mark. If an CWR confirmation will be received before the 287 ECE can be sent out with the next ACK, ECN feedback information 288 information could get lost. Thus a sender should set CWR only on 289 those data segments, that will actually trigger a (delayed) ACK. The 290 sender would need an additional control loop to estimated which data 291 segment will trigger an ACK. But such a more sophisticated 292 heuristics could extract congestion notifications more timely. Still 293 the CEG need to be increased by DeliveredData, as one or more CE 294 marked packets could be acknowledged by one delayed ACK. 296 3.2. Loss Detection 298 A ConEx sender MUST maintain a loss exposure gauge (LEG), indicating 299 the number of outstanding bytes that must be sent with the ConEx L 300 bit. When a data segment is retransmitted, LEG will be increased by 301 the size of the TCP payload bytes contained by the retransmission, 302 assuming equal sized segments such that the retransmitted packet will 303 have the same number of header bytes as the original ones. 305 Any retransmission may be spurious. To accommodate that, a ConEx 306 sender SHOULD make use of heuristics to detect such spurious 307 retransmissions (e.g. F-RTO [RFC5682], DSACK [RFC3708], and Eifel 308 [RFC3522], [RFC4015]). When such a heuristic has determined, that a 309 certain number of packets were retransmitted erroneously, the ConEx 310 sender should subtract the payload size of these TCP packets from 311 LEG. 313 3.2.1. Without SACK Support 315 If multiple losses occur within one RTT and SACK is not used, it may 316 take several RTTs until all lost data is retransmitted. With the 317 scheme described above, the ConEx information will be delayed 318 strongly but timeliness is important for ConEx. 320 For ConEx it is not important to know which data got lost but only 321 how much. During the first RTT after the initial loss detection, the 322 amount of received data and thus also the amount of lost data can be 323 estimated based on the number of received ACKs. Thus without SACK, 324 the needed information for the ConEx feedback can be available with 325 an additionally delay of one RTT by using the following estimation 326 algorithm: 328 If SACK information is not available, a ConEx sender should maintain 329 an additional Loss Estimation Counter (LEC). With the first 330 retransmission of a congestion event LEC is set to: 332 LEC = f - 3*SMSS 334 where f the is current flight size in bytes. At this point of time 335 in the transmission, in the worst case, all packets in flight minus 336 three that trigged the dupACks could have been lost. For each 337 retransmission that is sent, the LEG will still be increased but the 338 LEC will also be decreased by the payload size of the retransmission. 339 During the following RTT, LEC should be reduced by SMSS for each ACK 340 that is received. Thus after one RTT the LEC estimates the number of 341 outstanding bytes that should be ConEx L marked. To not further 342 delay this information, now LEG should be increased by LEC. From 343 then on every following retransmission should only reduce the LEC and 344 not increase the LEG until the LEC is zero, as those bytes were 345 already accounted. 347 4. Setting the ConEx Bits 349 ConEx is defined as a destination option for IPv6 350 [draft-ietf-conex-destopt]. The use of four bits have been defined, 351 namely the X (ConEx-capable), the L (loss experienced), the E (ECN 352 experienced) and C (credit) bit. 354 By setting the X bit a packet is marked as ConEx-capable. All 355 packets carrying payload MUST be marked with the X bit set including 356 retransmissions. No congestion feedback information are available 357 about control packets such as pure ACKs which are not carrying any 358 payload. Thus these packets should not be taken into account when 359 determining ConEx information. These packet MUST carry a ConEx 360 Destination Option with the X bit unset. 362 4.1. Setting the E and the L Bit 364 As long as the CEG or LEG counter is positive, ConEx-capable packets 365 SHOULD be marked with E or L respectively, and the CEG or LEG counter 366 is decreased by the TCP payload bytes carried in this packet. If the 367 CEG or LEG counter is negative, the respective counter SHOULD be 368 reset to zero within one RTT after it was decreased the last time or 369 one RTT after recovery if no further congestion occurred. 371 If SACK information is not available spurious retransmission are more 372 likely. In this case it might be valuable to slightly delay the 373 ConEx loss feedback until a spurious retransmission might be 374 detected. But the ConEx signal MUST NOT be delayed more than one RTT 375 if as long as data packets are sent out. 377 4.2. Credit Bits 379 The ConEx abstract mechanism requires that sufficient credit must be 380 signaled in advance to cover the expected congestion during the 381 feedback delay of one RTT. A ConEx sender should maintain a counter 382 of the sent credits c in bytes. If congestion occurs, credits will 383 be consumed and the c counter should be reduced by the number of 384 bytes that where lost or estimated to be ECN-marked. If the risk of 385 congestion was estimated wrongly and thus too few credits were sent, 386 the c counter becomes zero but can not get negative. 388 The number of credits sent should always equal the number of bytes in 389 flight, as all packets could potentially get lost or congestion 390 marked. Thus a ConEx sender should monitor the number of bytes in 391 flight f. If f ever becomes larger than c, the ConEx sender SHOULD 392 send new credits. Remember that c will be decreased if congestion 393 occurs. 395 In TCP Slow Start, the congestion window might grow much larger than 396 during the rest of the transmission. Thus a sender could consider to 397 sent fewer than f credits but risking potential penalization by an 398 audit. In any case the credits should at least cover the increase in 399 sending rate. As the sending rate increases exponentially in Slow 400 Start, thus double every RTT, a ConEx sender should at least cover 401 half the number of packets in flight by credits. Note, that the 402 number of losses or markings within one RTT does not only depend 403 actions taken by the sender. In general, the behavior of the cross 404 traffic, and if Active Queue Management (AQM) is used, the respective 405 parameterization influence how many packets get dropped or marked. 406 But if the used AQM is not overly aggressive with ECN marking, 407 sending halve the flight size as credits should be sufficient for 408 both, congestion signaled by loss or ECN. Marking every fourth 409 packet will allow the respective number of credits in Slow Start as 410 it can be seen in Figure Figure 1. 412 RTT1 |------XC------>| 413 |------X------->| 414 |------X------->| credit=1 in_flight=3 415 | | 416 RTT2 |------X------->| 417 |------XC------>| 418 |------X------->| 419 |------X------->| 420 |------X------->| 421 |------XC------>| credit=3 in_flight=6 422 | | 423 RTT3 |------X------->| 424 |------X------->| 425 |------X------->| 426 |------XC------>| 427 |------X------->| 428 |------X------->| 429 |------X------->| 430 |------XC------>| 431 |------X------->| 432 |------X------->| 433 |------X------->| 434 |------XC------>| credit=6 in_flight=12 435 | . | 436 | : | 438 Figure 1: Credits in Slow Start (with an initial window of 3) 440 It is possible that the audit looses state due to e.g. rerouting or 441 memory limitations. Therefore, the sender needs to detect this case 442 and resend credits. Thus a ConEx sender should reset the credit 443 count c to zero if losses occur in two subsequent RTTs (assuming that 444 the sending rate was correctly reduced based on the received 445 congestion signal). 447 5. Loss of ConEx information 449 Of course also packets that carry a ConEx marking can get lost. A 450 ConEx sender must remember which packet was marked with either the L, 451 the E or the C bit. If one of these packets is detected to be lost, 452 the should increase the respective gauge, LEG or CEG, by the number 453 of lost payload bytes. 455 6. Timeliness of the ConEx Signals 457 ConEx signals can only be evaluated by a network nodewith a time 458 delay of about one RTT after the congestion occured. To avoiad 459 further delays, a ConEx sender SHOULD sent the ConEx signaling with 460 the next available packet. In cases where it is preferable to 461 slightly delay the ConEx signal, the sender MUST NOT delay the ConEx 462 signal more than one RTT. 464 Multiple ConEx bits may become available for signaling at the same 465 time, for example when an ACK is received by the sender, that 466 indicates at the same time that at least one segment has been lost, 467 and that one or more ECN marks were received. This may happen during 468 excessive congestion, where the queues overflow even though ECN was 469 used and currently all packets are marked, while others have to be 470 dropped nevertheless. Another possibility when this may happen are 471 lost ACKs, so that a subsequent ACK carries summary information not 472 previously available to the sender. As ConEx-capable packet can 473 carry different ConEx marks at the same time, these information do 474 not need to be distributed over several packets and thus can be sent 475 without further delay. 477 7. Acknowledgements 479 The authors would like to thank Bob Briscoe who contributed with this 480 initial ideas and valuable feedback. Moreover, thanks to Jana 481 Iyengar who provided valuable feedback. 483 8. IANA Considerations 485 This document does not have any requests to IANA. 487 9. Security Considerations 489 With some of the advanced ECN compatibility modes it is possible to 490 miss congestion notifications. Thus a sender will not decrease its 491 sending rate. If the congestion is persistent, the likelihood to 492 receive a congestion notification increases. In the worst case the 493 sender will still react correctly to loss. This will prevent a 494 congestion collapse. 496 10. References 498 10.1. Normative References 500 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 501 Selective Acknowledgment Options", RFC 2018, October 1996. 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, March 1997. 506 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 507 of Explicit Congestion Notification (ECN) to IP", RFC 508 3168, September 2001. 510 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 511 Control", RFC 5681, September 2009. 513 [draft-ietf-conex-abstract-mech] 514 Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 515 Concepts and Abstract Mechanism", draft-ietf-conex- 516 abstract-mech-06 (work in progress), October 2012. 518 [draft-ietf-conex-destopt] 519 Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6 520 Destination Option for ConEx", draft-ietf-conex-destopt-04 521 (work in progress), March 2013. 523 10.2. Informative References 525 [DCTCP] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, 526 P., Prabhakar, B., Sengupta, S., and M. Sridharan, "DCTCP: 527 Efficient Packet Transport for the Commoditized Data 528 Center", Jan 2010. 530 [I-D.briscoe-tsvwg-re-ecn-tcp] 531 Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith, 532 "Re-ECN: Adding Accountability for Causing Congestion to 533 TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-09 (work in 534 progress), October 2010. 536 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 537 for TCP", RFC 3522, April 2003. 539 [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective 540 Acknowledgement (DSACKs) and Stream Control Transmission 541 Protocol (SCTP) Duplicate Transmission Sequence Numbers 542 (TSNs) to Detect Spurious Retransmissions", RFC 3708, 543 February 2004. 545 [RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm 546 for TCP", RFC 4015, February 2005. 548 [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. 549 Ramakrishnan, "Adding Explicit Congestion Notification 550 (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, June 551 2009. 553 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 554 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 555 Spurious Retransmission Timeouts with TCP", RFC 5682, 556 September 2009. 558 [RFC6789] Briscoe, B., Woundy, R., and A. Cooper, "Congestion 559 Exposure (ConEx) Concepts and Use Cases", RFC 6789, 560 December 2012. 562 [draft-briscoe-tsvwg-byte-pkt-mark] 563 Briscoe, B. and J. Manner, "Byte and Packet Congestion 564 Notification", draft-briscoe-tsvwg-byte-pkt-mark-010 (work 565 in progress), May 2013. 567 [draft-kuehlewind-tcpm-accurate-ecn] 568 Kuehlewind, M. and R. Scheffenegger, "More Accurate ECN 569 Feedback in TCP", draft-kuehlewind-tcpm-accurate-ecn-02 570 (work in progress), Jun 2013. 572 Appendix A. Revision history 574 RFC Editior: This section is to be removed before RFC publication. 576 00 ... initial draft, early submission to meet deadline. 578 01 ... refined draft, updated LEG "drain" from per-packet to RTT- 579 based. 581 02 ... added Section 5 and expanded discussion about ECN interaction. 583 03 ... expanded the discussion around credit bits. 585 04 ... review comments of Jana addressed. (Change in full compliance 586 mode.) 588 05 ... changes on Loss Detection without SACK, support of classic ECN 589 and credit handling. 591 Authors' Addresses 593 Mirja Kuehlewind (editor) 594 University of Stuttgart 595 Pfaffenwaldring 47 596 Stuttgart 70569 597 Germany 599 Email: mirja.kuehlewind@ikr.uni-stuttgart.de 601 Richard Scheffenegger 602 NetApp, Inc. 603 Am Euro Platz 2 604 Vienna 1120 605 Austria 607 Phone: +43 1 3676811 3146 608 Email: rs@netapp.com