idnits 2.17.1 draft-ietf-conex-tcp-modifications-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3910 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'DCTCP' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'I-D.briscoe-tsvwg-re-ecn-tcp' is defined on line 555, 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: January 16, 2014 NetApp, Inc. 6 July 15, 2013 8 TCP modifications for Congestion Exposure 9 draft-ietf-conex-tcp-modifications-04 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 January 16, 2014. 35 Copyright Notice 37 Copyright (c) 2013 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 with/without SACK . . . . . . . . . . . . 8 60 4. Setting the ConEx Bits . . . . . . . . . . . . . . . . . . . 9 61 4.1. Setting the E and the L Bit . . . . . . . . . . . . . . . 9 62 4.2. Credit Bits . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.3. Loss of ConEx information . . . . . . . . . . . . . . . . 10 64 5. Timeliness of the ConEx Signals . . . . . . . . . . . . . . . 11 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 70 9.2. Informative References . . . . . . . . . . . . . . . . . 12 71 Appendix A. Revision history . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 Congestion Exposure (ConEx) is a mechanism by which senders inform 77 the network about the congestion encountered by previous packets on 78 the same flow. ConEx concepts and use cases are further explained in 79 [RFC6789]. The abstract ConEx mechanism is explained in 80 [draft-ietf-conex-abstract-mech]. This document describes the 81 necessary modifications to use ConEx with the Transmission Control 82 Protocol (TCP). 84 ConEx is defined as a destination option for IPv6 85 [draft-ietf-conex-destopt]. The use of four bits have been defined, 86 namely the X (ConEx-capable), the L (loss experienced), the E (ECN 87 experienced) and C (credit) bit. 89 The ConEx signal is based on loss or Explicit Congestion Notification 90 (ECN) marks [RFC3168] as a congestion indication. This congestion 91 information is retrieved by the sender based on existing feedback 92 mechanisms from the receiver to the sender in TCP. 94 This document describes mechanisms for both TCP with and without the 95 Selective Acknowledgment (SACK) extension [RFC2018]. However, ConEx 96 benefits from more accurate information about the number of packets 97 dropped in the network. We therefore recommend using the SACK 98 extension when using TCP with ConEx. 100 While loss-based congestion feedback should be minimized, ECN could 101 actually provide more fine-grained feedback information. ConEx-based 102 traffic measurement or management mechanism would benefit from this. 103 Unfortunately the current ECN does not reflect multiple congestion 104 markings which occur within the same Round-Trip Time (RTT). A more 105 accurate feedback extension to ECN is defined in a separate document 106 [draft-kuehlewind-tcpm-accurate-ecn], as this is also useful for 107 other mechanisms. 109 1.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2. Sender-side Modifications 117 A ConEx sender MUST negotiate for both SACK and ECN or the more 118 accurate ECN feedback in the TCP handshake if these TCP extension are 119 available at the sender. Thus a ConEx SHOULD also implement SACK and 120 ECN. Depending on the capability of the receiver, the following 121 operation modes exist: 123 o SACK-accECN-ConEx (SACK and accurate ECN feedback) 125 o accECN-ConEx (no SACK but accurate ECN feedback) 127 o ECN-ConEx (no SACK and no accurate ECN feedback but 'classic' ECN) 129 o SACK-ECN-ConEx (SACK and 'classic' instead of accurate ECN) 131 o SACK-ConEx (SACK but no ECN at all) 133 o Basic-ConEx (neither SACK nor ECN) 135 A ConEx sender MUST expose all congestion information to the network 136 according to the congestion information received by ECN or based on 137 loss information provided by the TCP feedback loop. A TCP sender 138 SHOULD account congestion byte-wise (and not packet-wise). A sender 139 MUST mark subsequent packets (after the congestion notification) with 140 the respective ConEx bit in the IP header. 142 With SACK only the number of lost payload bytes is known, but not the 143 number of packets carrying these bytes. With classic ECN only an 144 indication is given that a marking occurred which is not giving an 145 exact number of payload bytes nor packets. As network congestion is 146 usually byte-congestion [draft-briscoe-tsvwg-byte-pkt-mark], the 147 exact number of bytes should be taken into account if available to 148 make the ConEx signal as exact as possible. 150 The congestion accounting based on different operation modes is 151 described in the next section and the handling of the IPv6 bits 152 itself in the subsequent section afterwards. 154 3. Accounting congestion 156 A ConEx sender, thats accounts congestion byte-wise based on the 157 congestion information received by ECN or loss detection provided by 158 TCP, will maintain two different counters. These counters hold the 159 number outstanding bytes that need to be ConEx marked either with the 160 E bit or the L bit. 162 The outstanding bytes accounted based on ECN feedback information are 163 maintained in the congestion exposure gauge (CEG). The accounting of 164 these bytes from the ECN feedback is explained in more detail next in 165 Section 3.1. 167 The outstanding bytes for congestion indications based on loss are 168 maintained in the loss exposure gauge (LEG) and the accounting is 169 explained in subsequent to the CEG accounting in Section 3.2. 171 Furthermore, those counters will be reduced every time a ConEx 172 capable packet with the E or L bit set is sent. This is explained 173 from both counters in Section 4.1. 175 Usually all bytes of an IP packet must be accounted. Therefore the 176 sender SHOULD take the headers into account, too. If equal sized 177 packets, or at least equally distributed packet sizes can be assumed, 178 the sender MAY only account the TCP payload bytes. In this case 179 there should be about the same number of ConEx marked packets as the 180 original packets that were causing the congestion. Thus both contain 181 about the same number of header bytes. This case is assumed in the 182 following sections. 184 Otherwise if this is not the case and a sender sends different sized 185 packets (with unequally distributed packet sizes), the sender needs 186 to memorize or estimate the number of ECN-marked or lost packets. A 187 sender might be able to reconstruct the number of packets and thus 188 the header bytes if the packet sizes of the last RTT are known. 189 Otherwise if no additional information is available the worst case 190 number of headers should be estimated in a conservative way based on 191 a 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. 223 Unfortunately in case of duplicate acknowledgements the number of 224 newly acknowledged bytes will be zero even though (CE marked) data 225 has been received. Therefore, we increase the CEG by DeliveredData, 226 as defined below: 228 DeliveredData covers the number of bytes which has been newly 229 delivered to the receiver. Therefore on each arrival of an ACK, 230 DeliveredData will be calculated by the newly acknowledged bytes 231 (acked_bytes) as indicated by the current ACK, relative to all past 232 ACKs. Moreover with SACK, DeliveredData is increased by the number 233 of bytes provided by (new) SACK information (SACK_diff). Note, if 234 less unacknowledged bytes are announced in the new SACK information 235 than in the previous ACK, SACK_diff can be negative. In this case, 236 data is newly acknowledged (in acked_byte), that has previously 237 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 the newly acknowledged bytes, 242 minus 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 has to be increased by the amount of bytes 262 sent which were marked: 264 CEG += min(SMSS*D, DeliveredData) 266 3.1.2. Classic ECN support 268 A ConEx sender that communicates with a classic ECN receiver 269 (conforming to [RFC3168] or [RFC5562]) MAY run in one of these modes: 271 o Full compliance mode: 273 The ConEx sender fully conforms to all the semantics of the ECN 274 signaling as defined by [RFC5562]. In this mode, only a single 275 congestion indication can be signaled by the receiver per RTT. 276 Whenever the ECE flag toggles from "0" to "1", the gauge CEG is 277 increased at maximum by the SMSS: 279 CEG += min(SMSS, DeliveredData) 281 Note that most often, a session adhering to these semantics may 282 not provide enough ConEx marks as usually more than one CE mark 283 will occur during one congestion event (within one RTT). We 284 assume that the credits build up during the Slow Start phase will 285 cover the mismatch for short connections with only light 286 congestion. Otherwise this will cause appropriate sanctions by an 287 audit device in a ConEx enabled network. To avoid this in any 288 case, on whole RTT of packets need to be regarded as congestion 289 marked. Thus increasing the CEG by the number of DeliveredData 290 for each ACK with the ECE bit set, would cover the worst case 291 estimation. 293 o Simple compatibility mode: 295 The sender will set the CWR permanently to force the receiver to 296 signal only one ECE per CE mark. Unfortunately, the use of 297 delayed ACKs [RFC5681], as it is usually done today, will prevent 298 a feedback of every CE mark. An CWR confirmation will be received 299 before the ECE can be sent out with the next ACK. With an ACK 300 rate of M, about M-1/M CE indications will not be signaled back by 301 the receiver (e.g. 50% with M=2 for delayed ACKs). Thus, in this 302 mode the ConEx sender MUST increase CEG as if M congestion 303 notification were received for each received ECE signal: 305 CEG += min(M*SMSS, DeliveredData + (M-1)*SMSS) 307 In case of a congestion event with low congestion (that means when 308 only a very smaller number of packets get marked), the sender 309 might miss the whole congestion event. Even though the sender 310 will send sufficient ConEx marks on average due to the scheme 311 proposed above, these ConEx marks might be shifted in time and an 312 audit might penalize this behavior. Regarding congestion control, 313 it is not a general problem to miss a congestion event as, by 314 chance, a marking scheme in the network node might also miss a 315 certain flow. In the case where no other flow is reacting, the 316 congestion level will increase and it will get more likely that 317 the congestion feedback is delivered. To provide a fair share 318 over time, a TCP sender implementing this simple ECN compatibility 319 mode could react more strongly when receiving an ECN feedback 320 signal. This of course depends on the congestion control used. 322 o Advanced compatibility mode: 324 To avoid the loss of ECN feedback information in the proposed 325 simple compatibility mode, a sender could set CWR only on those 326 data segments, that will actually trigger a (delayed) ACK. The 327 sender would need an additional control loop to estimated which 328 data segment will trigger an ACK. Such a more sophisticated 329 heuristics could extract congestion notifications more timely. In 330 addition, if this advanced compatibility mode is used, further 331 heuristics SHOULD be implemented, to determine the value of each 332 ECE notification. E.g. for each consecutive ACK received with the 333 ECE flag set, CEG should be increased by min( M*SSMS, 334 DeliveredData). Else if the predecessor ACK was received with the 335 ECE flag cleared, CEG need only be increase at maximum by one 336 SMSS: 338 if previous_marked: CEG += min( M*SSMS, DeliveredData) 339 else: CEG += min(SMSS, DeliveredData) 341 This heuristic is conservative during more serious congestion, and 342 more relaxed at low congestion levels. 344 3.2. Loss Detection with/without SACK 346 For all the data segments that are determined by a ConEx sender as 347 lost, (at least) the same number of TCP payload bytes MUST be be sent 348 with the ConEx L bit set. Loss detection typically happens by use of 349 duplicate ACKs, or the firing of the retransmission timer. A ConEx 350 sender MUST maintain a loss exposure gauge (LEG), indicating the 351 number of outstanding bytes that must be sent with the ConEx L bit. 352 When a data segment is retransmitted, LEG will be increased by the 353 size of the TCP payload bytes containing the retransmission, assuming 354 equal sized segments such that the retransmitted packet will have the 355 same number of header as the original ones. When sending subsequent 356 segments, the ConEx L bit is set as long as LEG is positive, and LEG 357 is decreased by the size of the sent TCP payload bytes with the ConEx 358 L bit set. 360 Any retransmission may be spurious. To accommodate that, a ConEx 361 sender SHOULD make use of heuristics to detect such spurious 362 retransmissions (e.g. F-RTO [RFC5682], DSACK [RFC3708], and Eifel 363 [RFC3522], [RFC4015]). When such a heuristic has determined, that a 364 certain number of packets were retransmitted erroneously, the ConEx 365 sender should subtract the payload size of these TCP packets from 366 LEG. 368 Note that the above heuristics delays the ConEx signal by one 369 segment, and also decouples them from the retransmissions themselves, 370 as some control packets (e.g. pure ACKs, window probes, or window 371 updates) may be sent in between data segment retransmissions. A 372 simpler approach would be to set the ConEx signal for each 373 retransmitted data segment. However, it is important to remember, 374 that a ConEx signal and TCP segments do not natively belong together. 376 If SACK is not available or SACK information has been reset for any 377 reason, spurious retransmission are more likely. In this case it 378 might be valuable to slightly delay the ConEx loss feedback until a 379 spurious retransmission might be detected. But the ConEx signal MUST 380 NOT be delayed more than one RTT. 382 4. Setting the ConEx Bits 384 ConEx is defined as a destination option for IPv6 385 [draft-ietf-conex-destopt]. The use of four bits have been defined, 386 namely the X (ConEx-capable), the L (loss experienced), the E (ECN 387 experienced) and C (credit) bit. 389 By setting the X bit a packet is marked as ConEx-capable. All 390 packets carrying payload MUST be marked with the X bit set including 391 retransmissions. No congestion feedback information are available 392 about control packets as pure ACKs which are not carrying any 393 payload. Thus these packet should not be taken into account when 394 determining ConEx information. These packet MUST carry a ConEx 395 Destination Option with the X bit unset. 397 4.1. Setting the E and the L Bit 399 As long as the CEG or LEG counter is positive, ConEx-capable packets 400 SHOULD be marked with E or L respectively, and the CEG or LEG counter 401 is decreased by the TCP payload bytes carried in this packet. If the 402 CEG or LEG counter is negative, the respective counter SHOULD be 403 reset to zero within one RTT after it was decreased the last time or 404 one RTT after recovery if no further congestion occurred. 406 4.2. Credit Bits 408 The ConEx abstract mechanism requires that the transport SHOULD 409 signal sufficient credit in advance to cover any reasonably expected 410 congestion during its feedback delay. To be very conservative the 411 number of credits would need to equal the number of packets in 412 flight, as every packet could get lost or congestion marked. With a 413 more moderate view, only an increase in the sending rate should cause 414 loss while the number of ECN markings within one RTT depends on 415 parameterization of the used Active Queue management (AQM). The 416 average or maximum number of ECN marks per congestion event could 417 potentially be estimated over time. This case is not further 418 expanded here. 420 In TCP Slow Start the sending rate will increase exponentially and 421 that means double every RTT. Thus the number of credits should equal 422 at least half the number of packets in flight in every RTT. If the 423 used AQM is not overly aggressive with ECN marking, maintaining the 424 number of credit as half the number of packets in flight should be 425 sufficient for both, congestion signaled by loss or ECN. Under the 426 assumption that all ConEx marks will not get invalid for the whole 427 Slow Start phase, marks of a previous RTT have to be added up. Thus 428 the marking of every fourth packet will allow sufficient credits in 429 Slow Start as it can be seen in Figure Figure 1. 431 RTT1 |------XC------>| 432 |------X------->| 433 |------X------->| credit=1 in_flight=3 434 | | 435 RTT2 |------X------->| 436 |------XC------>| 437 |------X------->| 438 |------X------->| 439 |------X------->| 440 |------XC------>| credit=3 in_flight=6 441 | | 442 RTT3 |------X------->| 443 |------X------->| 444 |------X------->| 445 |------XC------>| 446 |------X------->| 447 |------X------->| 448 |------X------->| 449 |------XC------>| 450 |------X------->| 451 |------X------->| 452 |------X------->| 453 |------XC------>| credit=6 in_flight=12 454 | . | 455 | : | 457 Figure 1: Credits in Slow Start (with an initial window of 3) 459 Moreover, a ConEx sender should maintain a counter of the sent 460 credits c. In Congestion Avoidance phase, the sender should to 461 monitor the number of packets in flight f. If f every gets larger 462 than c, the ConEx sender should send new credits. 464 The audit might loose state due to e.g. rerouting or memory 465 limitation. Therefore, the sender needs to detect this case and 466 resend credits. Thus a ConEx sender should reset the credit count c 467 if losses occur in two subsequent RTTs (assuming that the sending 468 rate was correctly reduced based on the received congestion signal). 470 4.3. Loss of ConEx information 472 The audit can have wrong information if e.g. ConEx got lost on the 473 channel (or a wrong number of ConEx marking has been estimated by the 474 sender due to a lack of feedback information). In this case the 475 audit might penalize a sender wrongly. The ConEx sender should 476 detect this case and send further credits which should solve the 477 situation (see Section 4.2). 479 5. Timeliness of the ConEx Signals 481 ConEx signals will anyway be evaluated with a slight time delay of 482 about one RTT by a network node. Therefore, it is not absolutely 483 necessary to immediately signal ConEx bits when they become known 484 (e.g. L and E bits), but a sender SHOULD sent the ConEx signaling 485 with the next available packet. In cases where it is preferable to 486 slightly delay the ConEx signal, the sender MUST NOT delay the ConEx 487 signal more than one RTT. 489 Multiple ConEx bits may become available for signaling at the same 490 time, for example when an ACK is received by the sender, that 491 indicates that at least one segment has been lost, and that one or 492 more ECN marks were received at the same time. This may happen 493 during excessive congestion, where buffer queues overflow and some 494 packets are marked, while others have to be dropped nevertheless. 495 Another possibility when this may happen are lost ACKs, so that a 496 subsequent ACK carries summary information not previously available 497 to the sender. As ConEx-capable packet can carry different ConEx 498 marks at the same time, these information do not need to be 499 distributed over several packets and thus can be sent without further 500 delay. 502 6. Acknowledgements 504 The authors would like to thank Bob Briscoe who contributed with this 505 initial ideas and valuable feedback. Moreover, thanks to Jana 506 Iyengar who provided valuable feedback. 508 7. IANA Considerations 510 This document does not have any requests to IANA. 512 8. Security Considerations 514 With some of the advanced ECN compatibility modes it is possible to 515 miss congestion notifications. Thus a sender will not decrease its 516 sending rate. If the congestion is persistent, the likelihood to 517 receive a congestion notification increases. In the worst case the 518 sender will still react correctly to loss. This will prevent a 519 congestion collapse. 521 9. References 523 9.1. Normative References 525 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 526 Selective Acknowledgment Options", RFC 2018, October 1996. 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, March 1997. 531 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 532 of Explicit Congestion Notification (ECN) to IP", RFC 533 3168, September 2001. 535 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 536 Control", RFC 5681, September 2009. 538 [draft-ietf-conex-abstract-mech] 539 Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 540 Concepts and Abstract Mechanism", draft-ietf-conex- 541 abstract-mech-06 (work in progress), October 2012. 543 [draft-ietf-conex-destopt] 544 Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6 545 Destination Option for ConEx", draft-ietf-conex-destopt-04 546 (work in progress), March 2013. 548 9.2. Informative References 550 [DCTCP] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, 551 P., Prabhakar, B., Sengupta, S., and M. Sridharan, "DCTCP: 552 Efficient Packet Transport for the Commoditized Data 553 Center", Jan 2010. 555 [I-D.briscoe-tsvwg-re-ecn-tcp] 556 Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith, 557 "Re-ECN: Adding Accountability for Causing Congestion to 558 TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-09 (work in 559 progress), October 2010. 561 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 562 for TCP", RFC 3522, April 2003. 564 [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective 565 Acknowledgement (DSACKs) and Stream Control Transmission 566 Protocol (SCTP) Duplicate Transmission Sequence Numbers 567 (TSNs) to Detect Spurious Retransmissions", RFC 3708, 568 February 2004. 570 [RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm 571 for TCP", RFC 4015, February 2005. 573 [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. 574 Ramakrishnan, "Adding Explicit Congestion Notification 575 (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, June 576 2009. 578 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 579 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 580 Spurious Retransmission Timeouts with TCP", RFC 5682, 581 September 2009. 583 [RFC6789] Briscoe, B., Woundy, R., and A. Cooper, "Congestion 584 Exposure (ConEx) Concepts and Use Cases", RFC 6789, 585 December 2012. 587 [draft-briscoe-tsvwg-byte-pkt-mark] 588 Briscoe, B. and J. Manner, "Byte and Packet Congestion 589 Notification", draft-briscoe-tsvwg-byte-pkt-mark-010 (work 590 in progress), May 2013. 592 [draft-kuehlewind-tcpm-accurate-ecn] 593 Kuehlewind, M. and R. Scheffenegger, "More Accurate ECN 594 Feedback in TCP", draft-kuehlewind-tcpm-accurate-ecn-02 595 (work in progress), Jun 2013. 597 Appendix A. Revision history 599 RFC Editior: This section is to be removed before RFC publication. 601 00 ... initial draft, early submission to meet deadline. 603 01 ... refined draft, updated LEG "drain" from per-packet to RTT- 604 based. 606 02 ... added Section 4.3 and expanded discussion about ECN 607 interaction. 609 03 ... expanded the discussion around credit bits. 611 04 ... review comments of Jana addressed. (Change in full compliance 612 mode.) 614 Authors' Addresses 616 Mirja Kuehlewind (editor) 617 University of Stuttgart 618 Pfaffenwaldring 47 619 Stuttgart 70569 620 Germany 622 Email: mirja.kuehlewind@ikr.uni-stuttgart.de 624 Richard Scheffenegger 625 NetApp, Inc. 626 Am Euro Platz 2 627 Vienna 1120 628 Austria 630 Phone: +43 1 3676811 3146 631 Email: rs@netapp.com