idnits 2.17.1 draft-ietf-tcpm-generalized-ecn-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 18, 2017) is 2411 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-03 == Outdated reference: A later version (-08) exists of draft-ietf-tsvwg-ecn-experimentation-05 == Outdated reference: A later version (-07) exists of draft-stewart-tsvwg-sctpecn-05 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft UC3M 4 Intended status: Experimental B. Briscoe 5 Expires: March 22, 2018 Simula Research Lab 6 September 18, 2017 8 ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control 9 Packets 10 draft-ietf-tcpm-generalized-ecn-00 12 Abstract 14 This document describes an experimental modification to ECN when used 15 with TCP. It allows the use of ECN on the following TCP packets: 16 SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions. 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 https://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 March 22, 2018. 35 Copyright Notice 37 Copyright (c) 2017 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Experiment Goals . . . . . . . . . . . . . . . . . . . . 4 55 1.3. Document Structure . . . . . . . . . . . . . . . . . . . 5 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.1. Network (e.g. Firewall) Behaviour . . . . . . . . . . . . 6 59 3.2. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . 6 60 3.2.1. SYN . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.2.2. SYN-ACK . . . . . . . . . . . . . . . . . . . . . . . 11 62 3.2.3. Pure ACK . . . . . . . . . . . . . . . . . . . . . . 12 63 3.2.4. Window Probe . . . . . . . . . . . . . . . . . . . . 13 64 3.2.5. FIN . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 3.2.6. RST . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 3.2.7. Retransmissions . . . . . . . . . . . . . . . . . . . 14 67 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 4.1. The Reliability Argument . . . . . . . . . . . . . . . . 15 69 4.2. SYNs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 4.2.1. Argument 1a: Unrecognized CE on the SYN . . . . . . . 16 71 4.2.2. Argument 1b: Unrecognized ECT on the SYN . . . . . . 18 72 4.2.3. Argument 2: DoS Attacks . . . . . . . . . . . . . . . 20 73 4.3. SYN-ACKs . . . . . . . . . . . . . . . . . . . . . . . . 20 74 4.4. Pure ACKs . . . . . . . . . . . . . . . . . . . . . . . . 22 75 4.4.1. Cwnd Response to CE-Marked Pure ACKs . . . . . . . . 23 76 4.4.2. ACK Rate Response to CE-Marked Pure ACKs . . . . . . 24 77 4.4.3. Summary: Enabling ECN on Pure ACKs . . . . . . . . . 25 78 4.5. Window Probes . . . . . . . . . . . . . . . . . . . . . . 25 79 4.6. FINs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 80 4.7. RSTs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 81 4.8. Retransmitted Packets. . . . . . . . . . . . . . . . . . 27 82 5. Interaction with popular variants or derivatives of TCP . . . 28 83 5.1. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 29 84 5.2. IW10 . . . . . . . . . . . . . . . . . . . . . . . . . . 29 85 5.3. TFO . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 88 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 91 9.2. Informative References . . . . . . . . . . . . . . . . . 31 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 94 1. Introduction 96 RFC 3168 [RFC3168] specifies support of Explicit Congestion 97 Notification (ECN) in IP (v4 and v6). By using the ECN capability, 98 switches performing Active Queue Management (AQM) can use ECN marks 99 instead of packet drops to signal congestion to the endpoints of a 100 communication. This results in lower packet loss and increased 101 performance. RFC 3168 also specifies support for ECN in TCP, but 102 solely on data packets. For various reasons it precludes the use of 103 ECN on TCP control packets (TCP SYN, TCP SYN-ACK, pure ACKs, Window 104 probes) and on retransmitted packets. RFC 3168 is silent about the 105 use of ECN on RST and FIN packets. RFC 5562 [RFC5562] is an 106 experimental modification to ECN that enables ECN support for TCP 107 SYN-ACK packets. 109 This document defines an experimental modification to ECN [RFC3168] 110 that enables ECN support on all the aforementioned types of TCP 111 packet. [I-D.ietf-tsvwg-ecn-experimentation] is a standards track 112 procedural device that relaxes standards track requirements in RFC 113 3168 that would otherwise preclude these experimental modifications. 115 The present document also considers the implications for common 116 derivatives and variants of TCP, such as SCTP [RFC4960], if the 117 experiment is successful. One particular variant of TCP adds 118 accurate ECN feedback (AccECN [I-D.ietf-tcpm-accurate-ecn]), without 119 which ECN support cannot be added to SYNs. Nonetheless, ECN support 120 can be added to all the other types of TCP packet whether or not 121 AccECN is also supported. 123 1.1. Motivation 125 The absence of ECN support on TCP control packets and retransmissions 126 has a potential harmful effect. In any ECN deployment, non-ECN- 127 capable packets suffer a penalty when they traverse a congested 128 bottleneck. For instance, with a drop probability of 1%, 1% of 129 connection attempts suffer a timeout of about 1 second before the SYN 130 is retransmitted, which is highly detrimental to the performance of 131 short flows. TCP control packets, such as TCP SYNs and pure ACKs, 132 are important for performance, so dropping them is best avoided. 134 Non-ECN control packets particularly harm performance in environments 135 where the ECN marking level is high. For example, [judd-nsdi] shows 136 that in a data centre (DC) environment where ECN is used (in 137 conjunction with DCTCP), the probability of being able to establish a 138 new connection using a non-ECN SYN packet drops to close to zero even 139 when there are only 16 ongoing TCP flows transmitting at full speed. 140 In this data centre context, the issue is that DCTCP's aggressive 141 response to packet marking leads to a high marking probability for 142 ECN-capable packets, and in turn a high drop probability for non-ECN 143 packets. Therefore non-ECN SYNs are dropped aggressively, rendering 144 it nearly impossible to establish a new connection in the presence of 145 even mild traffic load. 147 Finally, there are ongoing experimental efforts to promote the 148 adoption of a slightly modified variant of DCTCP (and similar 149 congestion controls) over the Internet to achieve low latency, low 150 loss and scalable throughput (L4S) for all communications 151 [I-D.briscoe-tsvwg-l4s-arch]. In such an approach, L4S packets 152 identify themselves using an ECN codepoint. With L4S and potentially 153 other similar cases, preventing TCP control packets from obtaining 154 the benefits of ECN would not only expose them to the prevailing 155 level of congestion loss, but it would also classify control packet 156 into a different queue with different network treatment, which may 157 also lead to reordering, further degrading TCP performance. 159 1.2. Experiment Goals 161 The goal of the experimental modifications defined in this document 162 is to allow the use of ECN on all TCP packets. Experiments are 163 expected in the public Internet as well as in controlled environments 164 to understand the following issues: 166 o How SYNs, Window probes, pure ACKs, FINs, RSTs and retransmissions 167 that carry the ECT(0), ECT(1) or CE codepoints are processed by 168 the TCP endpoints and the network (including routers, firewalls 169 and other middleboxes). In particular we would like to learn if 170 these packets are frequently blocked or if these packets are 171 usually forwarded and processed. 173 o The scale of deployment of the different flavours of ECN, 174 including [RFC3168], [RFC5562], [RFC3540] and 175 [I-D.ietf-tcpm-accurate-ecn]. 177 o How much the performance of TCP communications is improved by 178 allowing ECN marking of each packet type. 180 o To identify any issues (including security issues) raised by 181 enabling ECN marking of these packets. 183 The data gathered through the experiments described in this document, 184 particularly under the first 2 bullets above, will help in the design 185 of the final mechanism (if any) for adding ECN support to the 186 different packet types considered in this document. Whenever data 187 input is needed to assist in a design choice, it is spelled out 188 throughout the document. 190 Success criteria: The experiment will be a success if we obtain 191 enough data to have a clearer view of the deployability and benefits 192 of enabling ECN on all TCP packets, as well as any issues. If the 193 results of the experiment show that it is feasible to deploy such 194 changes; that there are gains to be achieved through the changes 195 described in this specification; and that no other major issues may 196 interfere with the deployment of the proposed changes; then it would 197 be reasonable to adopt the proposed changes in a standards track 198 specification that would update RFC 3168. 200 1.3. Document Structure 202 The remainder of this document is structured as follows. In 203 Section 2, we present the terminology used in the rest of the 204 document. In Section 3, we specify the modifications to provide ECN 205 support to TCP SYNs, pure ACKs, Window probes, FINs, RSTs and 206 retransmissions. We describe both the network behaviour and the 207 endpoint behaviour. Section 5 discusses variations of the 208 specification that will be necessary to interwork with a number of 209 popular variants or derivatives of TCP. RFC 3168 provides a number 210 of specific reasons why ECN support is not appropriate for each 211 packet type. In Section 4, we revisit each of these arguments for 212 each packet type to justify why it is reasonable to conduct this 213 experiment. 215 2. Terminology 217 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 218 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 219 document, are to be interpreted as described in [RFC2119]. 221 Pure ACK: A TCP segment with the ACK flag set and no data payload. 223 SYN: A TCP segment with the SYN (synchronize) flag set. 225 Window probe: Defined in [RFC0793], a window probe is a TCP segment 226 with only one byte of data sent to learn if the receive window is 227 still zero. 229 FIN: A TCP segment with the FIN (finish) flag set. 231 RST: A TCP segment with the RST (reset) flag set. 233 Retransmission: A TCP segment that has been retransmitted by the TCP 234 sender. 236 ECT: ECN-Capable Transport. One of the two codepoints ECT(0) or 237 ECT(1) in the ECN field [RFC3168] of the IP header (v4 or v6). An 238 ECN-capable sender sets one of these to indicate that both transport 239 end-points support ECN. When this specification says the sender sets 240 an ECT codepoint, by default it means ECT(0). Optionally, it could 241 mean ECT(1), which is in the process of being redefined for use by 242 L4S experiments [I-D.ietf-tsvwg-ecn-experimentation] 243 [I-D.briscoe-tsvwg-ecn-l4s-id]. 245 Not-ECT: The ECN codepoint set by senders that indicates that the 246 transport is not ECN-capable. 248 CE: Congestion Experienced. The ECN codepoint that an intermediate 249 node sets to indicate congestion [RFC3168]. A node sets an 250 increasing proportion of ECT packets to CE as the level of congestion 251 increases. 253 3. Specification 255 3.1. Network (e.g. Firewall) Behaviour 257 Previously the specification of ECN for TCP [RFC3168] required the 258 sender to set not-ECT on TCP control packets and retransmissions. 259 Some readers of RFC 3168 might have erroneously interpreted this as a 260 requirement for firewalls, intrusion detection systems, etc. to check 261 and enforce this behaviour. Section 4.3 of 262 [I-D.ietf-tsvwg-ecn-experimentation] updates RFC 3168 to remove this 263 ambiguity. It require firewalls or any intermediate nodes not to 264 treat certain types of ECN-capable TCP segment differently (except 265 potentially in one attack scenario). This is likely to only involve 266 a firewall rule change in a fraction of cases (at most 0.4% of paths 267 according to the tests reported in Section 4.2.2). 269 In case a TCP sender encounters a middlebox blocking ECT on certain 270 TCP segments, the specification below includes behaviour to fall back 271 to non-ECN. However, this loses the benefit of ECN on control 272 packets. So operators are RECOMMENDED to alter their firewall rules 273 to comply with the requirement referred to above (section 4.3 of 274 [I-D.ietf-tsvwg-ecn-experimentation]). 276 3.2. Endpoint Behaviour 278 The changes to the specification of TCP over ECN [RFC3168] defined 279 here solely alter the behaviour of the sending host for each half- 280 connection. All changes can be deployed at each end-point 281 independently of others. 283 The feedback behaviour at the receiver depends on whether classic ECN 284 TCP feedback [RFC3168] or Accurate ECN (AccECN) TCP feedback 285 [I-D.ietf-tcpm-accurate-ecn] has been negotiated. Nonetheless, 286 neither receiver feedback behaviour is altered by the present 287 specification. 289 For each type of control packet or retransmission, the following 290 sections detail changes to the sender's behaviour in two respects: i) 291 whether it sets ECT; and ii) its response to congestion feedback. 292 Table 1 summarises these two behaviours for each type of packet, but 293 the relevant subsection below should be referred to for the detailed 294 behaviour. The subsection on the SYN is more complex than the 295 others, because it has to include fall-back behaviour if the ECT 296 packet appears not to have got through, and caching of the outcome to 297 detect persistent failures. 299 +-----------+-----------------+-----------------+-------------------+ 300 | TCP | ECN field if | ECN field if | Congestion | 301 | packet | AccECN f/b | RFC3168 f/b | Response | 302 | type | negotiated* | negotiated* | | 303 +-----------+-----------------+-----------------+-------------------+ 304 | SYN | ECT | not-ECT | Reduce IW | 305 | | | | | 306 | SYN-ACK | ECT | ECT | Reduce IW as in | 307 | [RFC5562] | | | [RFC5562] | 308 | | | | | 309 | Pure ACK | ECT | ECT | Usual cwnd | 310 | | | | response and | 311 | | | | optionally | 312 | | | | [RFC5690] | 313 | | | | | 314 | W Probe | ECT | ECT | Usual cwnd | 315 | | | | response | 316 | | | | | 317 | FIN | ECT | ECT | None or | 318 | | | | optionally | 319 | | | | [RFC5690] | 320 | | | | | 321 | RST | ECT | ECT | N/A | 322 | | | | | 323 | Re-XMT | ECT | ECT | Usual cwnd | 324 | | | | response | 325 +-----------+-----------------+-----------------+-------------------+ 327 Window probe and retransmission are abbreviated to W Probe an Re-XMT. 328 * For a SYN, "negotiated" means "requested". 330 Table 1: Summary of sender behaviour. In each case the relevant 331 section below should be referred to for the detailed behaviour 333 It can be seen that the sender can set ECT in all cases, except if it 334 is not requesting AccECN feedback on the SYN. Therefore it is 335 RECOMMENDED that the experimental AccECN specification 336 [I-D.ietf-tcpm-accurate-ecn] is implemented (as well as the present 337 specification), because it is expected that ECT on the SYN will give 338 the most significant performance gain, particularly for short flows. 339 Nonetheless, this specification also caters for the case where AccECN 340 feedback is not implemented. 342 3.2.1. SYN 344 3.2.1.1. Setting ECT on the SYN 346 With classic [RFC3168] ECN feedback, the SYN was never expected to be 347 ECN-capable, so the flag provided to feed back congestion was put to 348 another use (it is used in combination with other flags to indicate 349 that the responder supports ECN). In contrast, Accurate ECN (AccECN) 350 feedback [I-D.ietf-tcpm-accurate-ecn] provides two codepoints in the 351 SYN-ACK for the responder to feed back whether or not the SYN arrived 352 marked CE. 354 Therefore, a TCP initiator MUST NOT set ECT on a SYN unless it also 355 attempts to negotiate Accurate ECN feedback in the same SYN. 357 For the experiments proposed here, if the SYN is requesting AccECN 358 feedback, the TCP sender will also set ECT on the SYN. It can ignore 359 the prohibition in section 6.1.1 of RFC 3168 against setting ECT on 360 such a SYN. 362 The following subsections about the SYN solely apply to this case 363 where the initiator sent an ECT SYN. 365 MEASUREMENTS NEEDED: Measurements are needed to verify that if SYN 366 packets with the ECT(0)/ECT(1)/CE codepoints are properly 367 delivered by the network. We need to learn if there are cases if 368 SYN packets are dropped because having the the ECT(0)/ECT(1)/CE 369 codepoints. We also need to learn if the network clears SYN 370 packet with the the ECT(0)/ECT(1)/CE codepoints. In addition, we 371 need measurements to learn how current deployed base of servers 372 react to SYN packets with ECT(0)/ECT(1)/CE codepoints whether they 373 discard it, or process it an return a SYN/ACK packet proceeding 374 with the connection. It would be also useful to measure how the 375 network elements and the servers react to all possible 376 combinations of ECN codepoints and NS/CWR/ECE flags. 378 3.2.1.2. Caching Lack of Support for ECT on SYNs 380 Until AccECN servers become widely deployed, a TCP initiator that 381 sets ECT on a SYN (which implies the same SYN also requests AccECN, 382 as required above) SHOULD also maintain a cache per server to record 383 any failure of previous attempts. 385 The initiator will record any server's SYN-ACK response that does not 386 support AccECN. Subsequently the initiator will not set ECT on a SYN 387 to such a server, but it can still always request AccECN support 388 (because the response will state any earlier stage of ECN evolution 389 that the server supports with no performance penalty). The initiator 390 will discover a server that has upgraded to support AccECN as soon as 391 it next connects, then it can remove the server from its cache and 392 subsequently always set ECT for that server. 394 If the initiator times out without seeing a SYN-ACK, it will also 395 cache this fact (see fall-back in Section 3.2.1.4 for details). 397 There is no need to cache successful attempts, because the default 398 ECT SYN behaviour performs optimally on success anyway. Servers that 399 do not support ECN as a whole probably do not need to be recorded 400 separately from non-support of AccECN because the response to a 401 request for AccECN immediately states which stage in the evolution of 402 ECN the server supports (AccECN [I-D.ietf-tcpm-accurate-ecn], classic 403 ECN [RFC3168] or no ECN). 405 The above strategy is named "optimistic ECT and cache failures". It 406 is believed to be sufficient based on initial measurements and 407 assumptions detailed in Section 4.2.1, which also gives alternative 408 strategies in case larger scale measurements uncover different 409 scenarios. 411 3.2.1.3. SYN Congestion Response 413 If the SYN-ACK returned to the TCP initiator confirms that the server 414 supports AccECN, it will also indicate whether or not the SYN was CE- 415 marked. If the SYN was CE-marked, the initiator MUST reduce its 416 Initial Window (IW) and SHOULD reduce it to 1 SMSS (sender maximum 417 segment size). 419 If the SYN-ACK shows that the server does not support AccECN, the TCP 420 initiator MUST conservatively reduce its Initial Window and SHOULD 421 reduce it to 1 SMSS. A reduction to greater than 1 SMSS MAY be 422 appropriate (see Section 4.2.1). Conservatism is necessary because a 423 non-AccECN SYN-ACK cannot show whether the SYN was CE-marked. 425 If the TCP initiator (host A) receives a SYN from the remote end 426 (host B) after it has sent a SYN to B, it indicates the (unusual) 427 case of a simultaneous open. Host A will respond with a SYN-ACK. 428 Host A will probably then receive a SYN-ACK in response to its own 429 SYN, after which it can follow the appropriate one of the two 430 paragraphs above. 432 In all the above cases, the initiator does not have to back off its 433 retransmission timer as it would in response to a timeout following 434 no response to its SYN [RFC6298], because both the SYN and the SYN- 435 ACK have been successfully delivered through the network. Also, the 436 initiator does not need to exit slow start or reduce ssthresh, which 437 is not even required when a SYN is lost [RFC5681]. 439 If an initial window of 10 (IW10 [RFC6928]) is implemented, Section 5 440 gives additional recommendations. 442 3.2.1.4. Fall-Back Following No Response to an ECT SYN 444 An ECT SYN might be lost due to an over-zealous path element (or 445 server) blocking ECT packets that do not conform to RFC 3168. 446 However, loss is commonplace for numerous other reasons, e.g. 447 congestion loss at a non-ECN queue on the forward or reverse path, 448 transmission errors, etc. Alternatively, the cause of the blockage 449 might be the attempt to negotiate AccECN, or possibly other unrelated 450 options on the SYN. 452 To expedite connection set-up if, after sending an ECT SYN, the 453 retransmission timer expires, the TCP initiator SHOULD send a SYN 454 with the not-ECT codepoint in the IP header. If other experimental 455 fields or options were on the SYN, it will also be necessary to 456 follow their specifications for fall-back too. It would make sense 457 to co- ordinate all the strategies for fall-back in order to isolate 458 the specific cause of the problem. 460 If the TCP initiator is caching failed connection attempts, it SHOULD 461 NOT give up using ECT on the first SYN of subsequent connection 462 attempts until it is clear that the blockage persistently and 463 specifically affects ECT on SYNs. This is because loss is so 464 commonplace for other reasons. Even if it does eventually decide to 465 give up on ECT on the SYN, it will probably not need to give up on 466 AccECN on the SYN. In any case, the cache should be arranged to 467 expire so that the initiator will infrequently attempt to check 468 whether the problem has been resolved. 470 Other fall-back strategies MAY be adopted where applicable (see 471 Section 4.2.2 for suggestions, and the conditions under which they 472 would apply). 474 3.2.2. SYN-ACK 476 3.2.2.1. Setting ECT on the SYN-ACK 478 For the experiments proposed here, the TCP implementation will set 479 ECT on SYN-ACKs. It can ignore the requirement in section 6.1.1 of 480 RFC 3168 to set not-ECT on a SYN-ACK. 482 The feedback behaviour by the initiator in response to a CE-marked 483 SYN-ACK from the responder depends on whether classic ECN feedback 484 [RFC3168] or AccECN feedback [I-D.ietf-tcpm-accurate-ecn] has been 485 negotiated. In either case no change is required to RFC 3168 or the 486 AccECN specification. 488 Some classic ECN implementations might ignore a CE-mark on a SYN-ACK, 489 or even ignore a SYN-ACK packet entirely if it is set to ECT or CE. 490 This is a possibility because an RFC 3168 implementation would not 491 necessarily expect a SYN-ACK to be ECN-capable. 493 FOR DISCUSSION: To eliminate this problem, the WG could decide to 494 prohibit setting ECT on SYN-ACKs unless AccECN has been 495 negotiated. However, this issue already came up when the IETF 496 first decided to experiment with ECN on SYN-ACKs [RFC5562] and it 497 was decided to go ahead without any extra precautionary measures 498 because the risk was low. This was because the probability of 499 encountering the problem was believed to be low and the harm if 500 the problem arose was also low (see Appendix B of RFC 5562). 502 MEASUREMENTS NEEDED: Server-side experiments could determine 503 whether this specific problem is indeed rare across the current 504 installed base of clients that support ECN. 506 3.2.2.2. SYN-ACK Congestion Response 508 A host that sets ECT on SYN-ACKs MUST reduce its initial window in 509 response to any congestion feedback, whether using classic ECN or 510 AccECN. It SHOULD reduce it to 1 SMSS. This is different to the 511 behaviour specified in an earlier experiment that set ECT on the SYN- 512 ACK [RFC5562]. This is justified in Section 4.3. 514 The responder does not have to back off its retransmission timer 515 because the ECN feedback proves that the network is delivering 516 packets successfully and is not severely overloaded. Also the 517 responder does not have to leave slow start or reduce ssthresh, which 518 is not even required when a SYN-ACK has been lost. 520 The congestion response to CE-marking on a SYN-ACK for a server that 521 implements either the TCP Fast Open experiment (TFO [RFC7413]) or the 522 initial window of 10 experiment (IW10 [RFC6928]) is discussed in 523 Section 5. 525 3.2.2.3. Fall-Back Following No Response to an ECT SYN-ACK 527 After the responder sends a SYN-ACK with ECT set, if its 528 retransmission timer expires it SHOULD resend a SYN-ACK with not-ECT 529 set. If other experimental fields or options were on the SYN, it 530 will also be necessary to follow their specifications for fall-back 531 too. It would make sense to co-ordinate all the strategies for fall- 532 back in order to isolate the specific cause of the problem. 534 The server MAY cache failed connection attempts, e.g. per client 535 access network. If the TCP server is caching failed connection 536 attempts, it SHOULD NOT give up using ECT on the first SYN-ACK of 537 subsequent connection attempts until it is clear that the blockage 538 persistently and specifically affects ECT on SYN-ACKs. This is 539 because loss is so commonplace for other reasons (see 540 Section 3.2.1.4). The cache should be arranged to expire so that the 541 server will infrequently attempt to check whether the problem has 542 been resolved. 544 This fall-back strategy is the same as that for ECT SYN-ACKs in 545 [RFC5562]. Other fall-back strategies MAY be adopted if found to be 546 more effective, e.g. one retransmission attempt using ECT before 547 reverting to not-ECT. 549 3.2.3. Pure ACK 551 For the experiments proposed here, the TCP implementation will set 552 ECT on pure ACKs. It can ignore the requirement in section 6.1.4 of 553 RFC 3168 to set not-ECT on a pure ACK. 555 A host that sets ECT on pure ACKs MUST reduce its congestion window 556 in response to any congestion feedback, in order to regulate any data 557 segments it might be sending amongst the pure ACKs. It MAY also 558 implement AckCC [RFC5690] to regulate the pure ACK rate, but this is 559 not required. Note that, in comparison, TCP Congestion Control 560 [RFC5681] does not require a TCP to detect or respond to loss of pure 561 ACKs at all; it requires no reduction in congestion window or ACK 562 rate. 564 The question of whether the receiver of pure ACKs is required to feed 565 back any CE marks on them is a matter for the relevant feedback 566 specification ([RFC3168] or [I-D.ietf-tcpm-accurate-ecn]). It is 567 outside the scope of the present specification. Currently AccECN 568 feedback is required to count CE marking of any control packet 569 including pure ACKs. Whereas RFC 3168 is silent on this point, so 570 feedback of CE-markings might be implementation specific (see 571 Section 4.4.1). 573 DISCUSSION: An AccECN deployment or an implementation of RFC 3168 574 that feeds back CE on pure ACKs will be at a disadvantage compared 575 to an RFC 3168 implementation that does not. To solve this, the 576 WG could decide to prohibit setting ECT on pure ACKs unless AccECN 577 has been negotiated. If it does, the penultimate sentence of the 578 Introduction will need to be modified. 580 MEASUREMENTS NEEDED: Measurements are needed to learn how the 581 deployed base of network elements and servers react to pure ACKs 582 marked with the ECT(0)/ECT(1)/CE codepoints, i.e. whether they are 583 dropped, codepoint cleared or processed. 585 3.2.4. Window Probe 587 For the experiments proposed here, the TCP sender will set ECT on 588 window probes. It can ignore the prohibition in section 6.1.6 of RFC 589 3168 against setting ECT on a window probe. 591 A window probe contains a single octet, so it is no different from a 592 regular TCP data segment. Therefore a TCP receiver will feed back 593 any CE marking on a window probe as normal (either using classic ECN 594 feedback or AccECN feedback). The sender of the probe will then 595 reduce its congestion window as normal. 597 A receive window of zero indicates that the application is not 598 consuming data fast enough and does not imply anything about network 599 congestion. Once the receive window opens, the congestion window 600 might become the limiting factor, so it is correct that CE-marked 601 probes reduce the congestion window. However, CE-marking on window 602 probes does not reduce the rate of the probes themselves. This is 603 unlikely to present a problem, given the duration between window 604 probes doubles [RFC1122] as long as the receiver is advertising a 605 zero window (currently minimum 1 second, maximum at least 1 minute 606 [RFC6298]). 608 MEASUREMENTS NEEDED: Measurements are needed to learn how the 609 deployed base of network elements and servers react to Window 610 probes marked with the ECT(0)/ECT(1)/CE codepoints, i.e. whether 611 they are dropped, codepoint cleared or processed. 613 3.2.5. FIN 615 A TCP implementation can set ECT on a FIN. 617 The TCP data receiver MUST ignore the CE codepoint on incoming FINs 618 that fail any validity check. The validity check in section 5.2 of 619 [RFC5961] is RECOMMENDED. 621 A congestion response to a CE-marking on a FIN is not required. 623 After sending a FIN, the endpoint will not send any more data in the 624 connection. Therefore, even if the FIN-ACK indicates that the FIN 625 was CE-marked (whether using classic or AccECN feedback), reducing 626 the congestion window will not affect anything. 628 After sending a FIN, a host might send one or more pure ACKs. If it 629 is using one of the techniques in Section 3.2.3 to regulate the 630 delayed ACK ratio for pure ACKs, it could equally be applied after a 631 FIN. But this is not required. 633 MEASUREMENTS NEEDED: Measurements are needed to learn how the 634 deployed base of network elements and servers react to FIN packets 635 marked with the ECT(0)/ECT(1)/CE codepoints, i.e. whether they are 636 dropped, codepoint cleared or processed. 638 3.2.6. RST 640 A TCP implementation can set ECT on a RST. 642 The "challenge ACK" approach to checking the validity of RSTs 643 (section 3.2 of [RFC5961] is RECOMMENDED at the data receiver. 645 A congestion response to a CE-marking on a RST is not required (and 646 actually not possible). 648 MEASUREMENTS NEEDED: Measurements are needed to learn how the 649 deployed base of network elements and servers react to RST packets 650 marked with the ECT(0)/ECT(1)/CE codepoints, i.e. whether they are 651 dropped, codepoint cleared or processed. 653 3.2.7. Retransmissions 655 For the experiments proposed here, the TCP sender will set ECT on 656 retransmitted segments. It can ignore the prohibition in section 657 6.1.5 of RFC 3168 against setting ECT on retransmissions. 659 Nonetheless, the TCP data receiver MUST ignore the CE codepoint on 660 incoming segments that fail any validity check. The validity check 661 in section 5.2 of [RFC5961] is RECOMMENDED. This will effectively 662 mitigate an attack that uses spoofed data packets to fool the 663 receiver into feeding back spoofed congestion indications to the 664 sender, which in turn would be fooled into continually halving its 665 congestion window. 667 If the TCP sender receives feedback that a retransmitted packet was 668 CE-marked, it will react as it would to any feedback of CE-marking on 669 a data packet. 671 MEASUREMENTS NEEDED: Measurements are needed to learn how the 672 deployed base of network elements and servers react to 673 retransmissions marked with the ECT(0)/ECT(1)/CE codepoints, i.e. 674 whether they are dropped, codepoint cleared or processed. 676 4. Rationale 678 This section is informative, not normative. It presents counter- 679 arguments against the justifications in the RFC series for disabling 680 ECN on TCP control segments and retransmissions. It also gives 681 rationale for why ECT is safe on control segments that have not, so 682 far, been mentioned in the RFC series. First it addresses over- 683 arching arguments used for most packet types, then it addresses the 684 specific arguments for each packet type in turn. 686 4.1. The Reliability Argument 688 Section 5.2 of RFC 3168 states: 690 "To ensure the reliable delivery of the congestion indication of 691 the CE codepoint, an ECT codepoint MUST NOT be set in a packet 692 unless the loss of that packet [at a subsequent node] in the 693 network would be detected by the end nodes and interpreted as an 694 indication of congestion." 696 We believe this argument is misplaced. TCP does not deliver most 697 control packets reliably. So it is more important to allow control 698 packets to be ECN-capable, which greatly improves reliable delivery 699 of the control packets themselves (see motivation in Section 1.1). 700 ECN also improves the reliability and latency of delivery of any 701 congestion notification on control packets, particularly because TCP 702 does not detect the loss of most types of control packet anyway. 703 Both these points outweigh by far the concern that a CE marking 704 applied to a control packet by one node might subsequently be dropped 705 by another node. 707 The principle to determine whether a packet can be ECN-capable ought 708 to be "do no extra harm", meaning that the reliability of a 709 congestion signal's delivery ought to be no worse with ECN than 710 without. In particular, setting the CE codepoint on the very same 711 packet that would otherwise have been dropped fulfills this 712 criterion, since either the packet is delivered and the CE signal is 713 delivered to the endpoint, or the packet is dropped and the original 714 congestion signal (packet loss) is delivered to the endpoint. 716 The concern about a CE marking being dropped at a subsequent node 717 might be motivated by the idea that ECN-marking a packet at the first 718 node does not remove the packet, so it could go on to worsen 719 congestion at a subsequent node. However, it is not useful to reason 720 about congestion by considering single packets. The departure rate 721 from the first node will generally be the same (fully utilized) with 722 or without ECN, so this argument does not apply. 724 4.2. SYNs 726 RFC 5562 presents two arguments against ECT marking of SYN packets 727 (quoted verbatim): 729 "First, when the TCP SYN packet is sent, there are no guarantees 730 that the other TCP endpoint (node B in Figure 2) is ECN-Capable, 731 or that it would be able to understand and react if the ECN CE 732 codepoint was set by a congested router. 734 Second, the ECN-Capable codepoint in TCP SYN packets could be 735 misused by malicious clients to "improve" the well-known TCP SYN 736 attack. By setting an ECN-Capable codepoint in TCP SYN packets, a 737 malicious host might be able to inject a large number of TCP SYN 738 packets through a potentially congested ECN-enabled router, 739 congesting it even further." 741 The first point actually describes two subtly different issues. So 742 below three arguments are countered in turn. 744 4.2.1. Argument 1a: Unrecognized CE on the SYN 746 This argument certainly applied at the time RFC 5562 was written, 747 when no ECN responder mechanism had any logic to recognize or feed 748 back a CE marking on a SYN. The problem was that, during the 3WHS, 749 the flag in the TCP header for ECN feedback (called Echo Congestion 750 Experienced) had been overloaded to negotiate the use of ECN itself. 751 So there was no space for feedback in a SYN-ACK. 753 The accurate ECN (AccECN) protocol [I-D.ietf-tcpm-accurate-ecn] has 754 since been designed to solve this problem, using a two-pronged 755 approach. First AccECN uses the 3 ECN bits in the TCP header as 8 756 codepoints, so there is space for the responder to feed back whether 757 there was CE on the SYN. Second a TCP initiator can always request 758 AccECN support on every SYN, and any responder reveals its level of 759 ECN support: AccECN, classic ECN, or no ECN. Therefore, if a 760 responder does indicate that it supports AccECN, the initiator can be 761 sure that, if there is no CE feedback on the SYN-ACK, then there 762 really was no CE on the SYN. 764 An initiator can combine AccECN with three possible strategies for 765 setting ECT on a SYN: 767 (S1): Pessimistic ECT and cache successes: The initiator always 768 requests AccECN in the SYN, but without setting ECT. Then it 769 records those servers that confirm that they support AccECN in 770 a cache. On a subsequent connection to any server that 771 supports AccECN, the initiator can then set ECT on the SYN. 773 (S2): Optimistic ECT: The initiator always sets ECT optimistically 774 on the initial SYN and it always requests AccECN support. 775 Then, if the server response shows it has no AccECN logic (so 776 it cannot feed back a CE mark), the initiator conservatively 777 behaves as if the SYN was CE-marked, by reducing its initial 778 window. 780 A. No cache: The optimistic ECT strategy ought to work fairly 781 well without caching any responses. 783 B. Cache failures: The optimistic ECT strategy can be 784 improved by recording solely those servers that do not 785 support AccECN. On subsequent connections to these non- 786 AccECN servers, the initiator will still request AccECN 787 but not set ECT on the SYN. Then, the initiator can use 788 its full initial window (if it has enough request data to 789 need it). Longer term, as servers upgrade to AccECN, the 790 initiator will remove them from the cache and use ECT on 791 subsequent SYNs to that server. 793 (S3): ECT by configuration: In a controlled environment, the 794 administrator can make sure that servers support ECN-capable 795 SYN packets. Examples of controlled environments are single- 796 tenant DCs, and possibly multi-tenant DCs if it is assumed 797 that each tenant mostly communicates with its own VMs. 799 For unmanaged environments like the public Internet, pragmatically 800 the choice is between strategies (S1) and (S2B): 802 o The "pessimistic ECT and cache successes" strategy (S1) suffers 803 from exposing the initial SYN to the prevailing loss level, even 804 if the server supports ECT on SYNs, but only on the first 805 connection to each AccECN server. 807 o The "optimistic ECT and cache failures" strategy (S2B) exploits a 808 server's support for ECT on SYNs from the very first attempt. But 809 if the server turns out not to support AccECN, the initiator has 810 to conservatively limit its initial window - usually 811 unnecessarily. Nonetheless, initiator request data (as opposed to 812 server response data) is rarely larger than 1 SMSS anyway {ToDo: 813 reference? (this information was given informally by Yuchung 814 Cheng)}. 816 The normative specification for ECT on a SYN in Section 3.2.1 uses 817 the "optimistic ECT and cache failures" strategy (S2B) on the 818 assumption that an initial window of 1 SMSS is usually sufficient for 819 client requests anyway. Clients that often initially send more than 820 1 SMSS of data could use strategy (S1) during initial deployment, and 821 strategy (S2B) later (when the probability of servers supporting 822 AccECN and the likelihood of seeing some CE marking is higher). 823 Also, as deployment proceeds, caching successes (S1) starts off small 824 then grows, while caching failures (S2B) becomes large at first, then 825 shrinks. 827 MEASUREMENTS NEEDED: Measurements are needed to determine whether 828 one or the other strategy would be sufficient for any particular 829 client, or whether a particular client would need both strategies 830 in different circumstances. 832 4.2.2. Argument 1b: Unrecognized ECT on the SYN 834 Given, until now, ECT-marked SYN packets have been prohibited, it 835 cannot be assumed they will be accepted. According to a study using 836 2014 data [ecn-pam] from a limited range of vantage points, out of 837 the top 1M Alexa web sites, 4791 (0.82%) IPv4 sites and 104 (0.61%) 838 IPv6 sites failed to establish a connection when they received a TCP 839 SYN with any ECN codepoint set in the IP header and the appropriate 840 ECN flags in the TCP header. Of these, about 41% failed to establish 841 a connection due to the ECN flags in the TCP header even with a Not- 842 ECT ECN field in the IP header (i.e. despite full compliance with RFC 843 3168). Therefore adding the ECN-capability to SYNs was increasing 844 connection establishment failures by about 0.4%. 846 MEASUREMENTS NEEDED: In order to get these failures fixed, data 847 will be needed on which of the possible causes below is behind 848 them. 850 RFC 3168 says "a host MUST NOT set ECT on SYN [...] packets", but it 851 does not say what the responder should do if an ECN-capable SYN 852 arrives. So perhaps some responder implementations are checking that 853 the SYN complies with RFC 3168, then silently ignoring non-compliant 854 SYNs (or perhaps returning a RST). Also some middleboxes (e.g. 856 firewalls) might be discarding non-compliant SYNs. For the future, 857 [I-D.ietf-tsvwg-ecn-experimentation] updates RFC 3168 to clarify that 858 middleboxes "SHOULD NOT" do this, but that does not alter the past. 860 Whereas RSTs can be dealt with immediately, silent failures introduce 861 a retransmission timeout delay (default 1 second) at the initiator 862 before it attempts any fall back strategy. Ironically, making SYNs 863 ECN-capable is intended to avoid the timeout when a SYN is lost due 864 to congestion. Fortunately, where discard of ECN-capable SYNs is due 865 to policy it will occur predictably, not randomly like congestion. 866 So the initiator can avoid it by caching those sites that do not 867 support ECN-capable SYNs. This further justifies the use of the 868 "optimistic ECT and cache failures" strategy in Section 3.2.1. 870 MEASUREMENTS NEEDED: Experiments are needed to determine whether 871 blocking of ECT on SYNs is widespread, and how many occurrences of 872 problems would be masked by how few cache entries. 874 If blocking is too widespread for the "optimistic ECT and cache 875 failures" strategy (S2B), the "pessimistic ECT and cache successes" 876 strategy (Section 4.2.1) would be better. 878 MEASUREMENTS NEEDED: Then measurements would be needed on whether 879 failures were still widespread on the second connection attempt 880 after the more careful ("pessimistic") first connection. 882 If so, it might be necessary to send a not-ECT SYN soon after the 883 first ECT SYN (possibly with a delay between them - effectively 884 reducing the retransmission timeout) and only accept the non-ECT 885 connection if it returned first. This would reduce the performance 886 penalty for those deploying ECT SYN support. 888 FOR DISCUSSION: If this becomes necessary, how much delay ought to 889 be required before the second SYN? Certainly less than the 890 standard RTO (1 second). But more or less than the maximum RTT 891 expected over the surface of the earth (roughly 250ms)? Or even 892 back-to-back? 894 However, based on the data above from [ecn-pam], even a cache of a 895 dozen or so sites ought to avoid all ECN-related performance problems 896 with roughly the Alexa top thousand. So it is questionable whether 897 sending two SYNs will be necessary, particularly given failures at 898 well-maintained sites could reduce further once ECT SYNs are 899 standardized. 901 4.2.3. Argument 2: DoS Attacks 903 [RFC5562] says that ECT SYN packets could be misused by malicious 904 clients to augment "the well-known TCP SYN attack". It goes on to 905 say "a malicious host might be able to inject a large number of TCP 906 SYN packets through a potentially congested ECN-enabled router, 907 congesting it even further." 909 We assume this is a reference to the TCP SYN flood attack (see 910 https://en.wikipedia.org/wiki/SYN_flood), which is an attack against 911 a responder end point. We assume the idea of this attack is to use 912 ECT to get more packets through an ECN-enabled router in preference 913 to other non-ECN traffic so that they can go on to use the SYN 914 flooding attack to inflict more damage on the responder end point. 915 This argument could apply to flooding with any type of packet, but we 916 assume SYNs are singled out because their source address is easier to 917 spoof, whereas floods of other types of packets are easier to block. 919 Mandating Not-ECT in an RFC does not stop attackers using ECT for 920 flooding. Nonetheless, if a standard says SYNs are not meant to be 921 ECT it would make it legitimate for firewalls to discard them. 922 However this would negate the considerable benefit of ECT SYNs for 923 compliant transports and seems unnecessary because RFC 3168 already 924 provides the means to address this concern. In section 7, RFC 3168 925 says "During periods where ... the potential packet marking rate 926 would be high, our recommendation is that routers drop packets rather 927 then set the CE codepoint..." and this advice is repeated in 928 [RFC7567] (section 4.2.1). This makes it harder for flooding packets 929 to gain from ECT. 931 Further experiments are needed to test how much malicious hosts can 932 use ECT to augment flooding attacks without triggering AQMs to turn 933 off ECN support (flying "just under the radar"). If it is found that 934 ECT can only slightly augment flooding attacks, the risk of such 935 attacks will need to be weighed against the performance benefits of 936 ECT SYNs. 938 4.3. SYN-ACKs 940 The proposed approach in Section 3.2.2 for experimenting with ECN- 941 capable SYN-ACKs is identical to the scheme called ECN+ [ECN-PLUS]. 942 In 2005, the ECN+ paper demonstrated that it could reduce the average 943 Web response time by an order of magnitude. It also argued that 944 adding ECT to SYN-ACKs did not raise any new security 945 vulnerabilities. 947 The IETF has already specified an experiment with ECN-capable SYN-ACK 948 packets [RFC5562]. It was inspired by the ECN+ paper, but it 949 specified a much more conservative congestion response to a CE-marked 950 SYN-ACK, called ECN+/TryOnce. This required the server to reduce its 951 initial window to 1 segment (like ECN+), but then the server had to 952 send a second SYN-ACK and wait for its ACK before it could continue 953 with its initial window of 1 SMSS. The second SYN-ACK of this 5-way 954 handshake had to carry no data, and had to disable ECN, but no 955 justification was given for these last two aspects. 957 The present ECN experiment uses the ECN+ congestion response, not 958 ECN+/TryOnce. First we argue against the rationale for ECN+/TryOnce 959 given in sections 4.4 and 6.2 of [RFC5562]. It starts with a rather 960 too literal interpretation of the requirement in RFC 3168 that says 961 TCP's response to a single CE mark has to be "essentially the same as 962 the congestion control response to a *single* dropped packet." TCP's 963 response to a dropped initial (SYN or SYN-ACK) packet is to wait for 964 the retransmission timer to expire (currently 1s). However, this 965 long delay assumes the worst case between two possible causes of the 966 loss: a) heavy overload; or b) the normal capacity-seeking behaviour 967 of other TCP flows. When the network is still delivering CE-marked 968 packets, it implies that there is an AQM at the bottleneck and that 969 it is not overloaded. This is because an AQM under overload will 970 disable ECN (as recommended in section 7 of RFC 3168 and repeated in 971 section 4.2.1 of RFC 7567). So scenario (a) can be ruled out. 972 Therefore, TCP's response to a CE-marked SYN-ACK can be similar to 973 its response to the loss of _any_ packet, rather than backing off as 974 if the special _initial_ packet of a flow has been lost. 976 How TCP responds to the loss of any single packet depends what it has 977 just been doing. But there is not really a precedent for TCP's 978 response when it experiences a CE mark having sent only one (small) 979 packet. If TCP had been adding one segment per RTT, it would have 980 halved its congestion window, but it hasn't established a congestion 981 window yet. If it had been exponentially increasing it would have 982 exited slow start, but it hasn't started exponentially increasing yet 983 so it hasn't established a slow-start threshold. 985 Therefore, we have to work out a reasoned argument for what to do. 986 If an AQM is CE-marking packets, it implies there is already a queue 987 and it is probably already somewhere around the AQM's operating point 988 - it is unlikely to be well below and it might be well above. So, it 989 does not seem sensible to add a number of packets at once. On the 990 other hand, it is highly unlikely that the SYN-ACK itself pushed the 991 AQM into congestion, so it will be safe to introduce another single 992 segment immediately (1 RTT after the SYN-ACK). Therefore, starting 993 to probe for capacity with a slow start from an initial window of 1 994 segment seems appropriate to the circumstances. This is the approach 995 adopted in Section 3.2.2. 997 4.4. Pure ACKs 999 Section 5.2 of RFC 3168 gives the following arguments for not 1000 allowing the ECT marking of pure ACKs (ACKs not piggy-backed on 1001 data): 1003 "To ensure the reliable delivery of the congestion indication of 1004 the CE codepoint, an ECT codepoint MUST NOT be set in a packet 1005 unless the loss of that packet in the network would be detected by 1006 the end nodes and interpreted as an indication of congestion. 1008 Transport protocols such as TCP do not necessarily detect all 1009 packet drops, such as the drop of a "pure" ACK packet; for 1010 example, TCP does not reduce the arrival rate of subsequent ACK 1011 packets in response to an earlier dropped ACK packet. Any 1012 proposal for extending ECN-Capability to such packets would have 1013 to address issues such as the case of an ACK packet that was 1014 marked with the CE codepoint but was later dropped in the network. 1015 We believe that this aspect is still the subject of research, so 1016 this document specifies that at this time, "pure" ACK packets MUST 1017 NOT indicate ECN-Capability." 1019 Later on, in section 6.1.4 it reads: 1021 "For the current generation of TCP congestion control algorithms, 1022 pure acknowledgement packets (e.g., packets that do not contain 1023 any accompanying data) MUST be sent with the not-ECT codepoint. 1024 Current TCP receivers have no mechanisms for reducing traffic on 1025 the ACK-path in response to congestion notification. Mechanisms 1026 for responding to congestion on the ACK-path are areas for current 1027 and future research. (One simple possibility would be for the 1028 sender to reduce its congestion window when it receives a pure ACK 1029 packet with the CE codepoint set). For current TCP 1030 implementations, a single dropped ACK generally has only a very 1031 small effect on the TCP's sending rate." 1033 We next address each of the arguments presented above. 1035 The first argument is a specific instance of the reliability argument 1036 for the case of pure ACKs. This has already been addressed by 1037 countering the general reliability argument in Section 4.1. 1039 The second argument says that ECN ought not to be enabled unless 1040 there is a mechanism to respond to it. However, actually there _is_ 1041 a mechanism to respond to congestion on a pure ACK that RFC 3168 has 1042 overlooked - the congestion window mechanism. When data segments and 1043 pure ACKs are interspersed, congestion notifications ought to 1044 regulate the congestion window, whether they are on data segments or 1045 on pure ACKs. Otherwise, if ECN is disabled on Pure ACKs, and if 1046 (say) 70% of the segments in one direction are Pure ACKs, about 70% 1047 of the congestion notifications will be missed and the data segments 1048 will not be correctly regulated. 1050 So RFC 3168 ought to have considered two congestion response 1051 mechanisms - reducing the congestion window (cwnd) and reducing the 1052 ACK rate - and only the latter was missing. Further, RFC 3168 was 1053 incorrect to assume that, if one ACK was a pure ACK, all segments in 1054 the same direction would be pure ACKs. Admittedly a continual stream 1055 of pure ACKs in one direction is quite a common case (e.g. a file 1056 download). However, it is also common for the pure ACKs to be 1057 interspersed with data segments (e.g. HTTP/2 browser requests 1058 controlling a web application). Indeed, it is more likely that any 1059 congestion experienced by pure ACKs will be due to mixing with data 1060 segments, either within the same flow, or within competing flows. 1062 This insight swings the argument towards enabling ECN on pure ACKs so 1063 that CE marks can drive the cwnd response to congestion (whenever 1064 data segments are interspersed with the pure ACKs). Then to 1065 separately decide whether an ACK rate response is also required (when 1066 they are ECN-enabled). The two types of response are addressed 1067 separately in the following two subsections, then a final subsection 1068 draws conclusions. 1070 4.4.1. Cwnd Response to CE-Marked Pure ACKs 1072 If the sender of pure ACKs sets them to ECT, the bullets below assess 1073 whether the three stages of the congestion response mechanism will 1074 all work for each type of congestion feedback (classic ECN [RFC3168] 1075 and AccECN [I-D.ietf-tcpm-accurate-ecn]): 1077 Detection: The receiver of a pure ACK can detect a CE marking on it: 1079 * Classic feedback: the receiver will not expect CE marks on pure 1080 ACKs, so it will be implementation-dependent whether it happens 1081 to check for CE marks on all packets. 1083 * AccECN feedback: the AccECN specification requires the receiver 1084 of any TCP packets to count any CE marks on them (whether or 1085 not control packets are ECN-capable). 1087 Feedback: TCP never ACKs a pure ACK, but the receiver of a CE-mark 1088 on a pure ACK can feed it back when it sends a subsequent data 1089 segment (if it ever does): 1091 * Classic feedback: the receiver (of the pure ACKs) would set the 1092 echo congestion experienced (ECE) flag in the TCP header as 1093 normal. 1095 * AccECN feedback: the receiver continually feeds back a count of 1096 the number of CE-marked packets that it has received (and, if 1097 possible, a count of CE-marked bytes). 1099 Congestion response: In either case (classic or AccECN feedback), if 1100 the TCP sender does receive feedback about CE-markings on pure 1101 ACKs, it will react in the usual way by reducing its congestion 1102 window accordingly. This will regulate the rate of any data 1103 packets it is sending amongst the pure ACKs. 1105 4.4.2. ACK Rate Response to CE-Marked Pure ACKs 1107 Reducing the congestion window will have no effect on the rate of 1108 pure ACKs. The worst case here is if the bottleneck is congested 1109 solely with pure ACKs, but it could also be problematic if a large 1110 fraction of the load was from unresponsive ACKs, leaving little or no 1111 capacity for the load from responsive data. 1113 Since RFC 3168 was published, Acknowledgement Congestion Control 1114 (AckCC) techniques have been documented in [RFC5690] (informational). 1115 So any pair of TCP end-points can choose to agree to regulate the 1116 delayed ACK ratio in response to lost or CE-marked pure ACKs. 1117 However, the protocol has a number of open deployment issues (e.g. it 1118 relies on two new TCP options, one of which is required on the SYN 1119 where option space is at a premium and, if either option is blocked 1120 by a middlebox, no fall-back behaviour is specified). The new TCP 1121 options addressed two problems, namely that TCP had: i) no mechanism 1122 to allow ECT to be set on pure ACKs; and ii) no mechanism to feed 1123 back loss or CE-marking of pure ACKs. A combination of the present 1124 specification and AccECN addresses both these problems, at least for 1125 ECN marking. So it might now be possible to design an ECN-specific 1126 ACK congestion control scheme without the extra TCP options proposed 1127 in RFC 5690. However, such a mechanism is out of scope of the 1128 present document. 1130 Setting aside the practicality of RFC 5690, the need for AckCC has 1131 not been conclusively demonstrated. It has been argued that the 1132 Internet has survived so far with no mechanism to even detect loss of 1133 pure ACKs. However, it has also been argued that ECN is not the same 1134 as loss. Packet discard can naturally thin the ACK load to whatever 1135 the bottleneck can support, whereas ECN marking does not (it queues 1136 the ACKs instead). Nonetheless, RFC 3168 (section 7) recommends that 1137 an AQM switches over from ECN marking to discard when the marking 1138 probability becomes high. Therefore discard can still be relied on 1139 to thin out ECN-enabled pure ACKs as a last resort. 1141 4.4.3. Summary: Enabling ECN on Pure ACKs 1143 In the case when AccECN has been negotiated, the arguments for ECT 1144 (and CE) on pure ACKs heavily outweigh those against. ECN is always 1145 more and never less reliable for delivery of congestion notification. 1146 The cwnd response has been overlooked as a mechanism for responding 1147 to congestion on pure ACKs, so it is incorrect not to set ECT on pure 1148 ACKs when they are interspersed with data segments. And when they 1149 are not, packet discard still acts as the "congestion response of 1150 last resort". In contrast, not setting ECT on pure ACKs is certainly 1151 detrimental to performance, because when a pure ACK is lost it can 1152 prevent the release of new data. Separately, AckCC (or perhaps an 1153 improved variant exploiting AccECN) could optionally be used to 1154 regulate the spacing between pure ACKs. However, it is not clear 1155 whether AckCC is justified. 1157 In the case when Classic ECN has been negotiated, there is still an 1158 argument for ECT (and CE) on pure ACKs, but it is less clear-cut. 1159 Some existing RFC 3168 implementations might happen to 1160 (unintentionally) provide the correct feedback to support a cwnd 1161 response. Even for those that did not, setting ECT on pure ACKs 1162 would still be better for performance than not setting it and do no 1163 extra harm. If AckCC was required, it is designed to work with RFC 1164 3168 ECN. 1166 4.5. Window Probes 1168 Section 6.1.6 of RFC 3168 presents only the reliability argument for 1169 prohibiting ECT on Window probes: 1171 "If a window probe packet is dropped in the network, this loss is 1172 not detected by the receiver. Therefore, the TCP data sender MUST 1173 NOT set either an ECT codepoint or the CWR bit on window probe 1174 packets. 1176 However, because window probes use exact sequence numbers, they 1177 cannot be easily spoofed in denial-of-service attacks. Therefore, 1178 if a window probe arrives with the CE codepoint set, then the 1179 receiver SHOULD respond to the ECN indications." 1181 The reliability argument has already been addressed in Section 4.1. 1183 Allowing ECT on window probes could considerably improve performance 1184 because, once the receive window has reopened, if a window probe is 1185 lost the sender will stall until the next window probe reaches the 1186 receiver, which might be after the maximum retransmission timeout (at 1187 least 1 minute [RFC6928]). 1189 On the bright side, RFC 3168 at least specifies the receiver 1190 behaviour if a CE-marked window probe arrives, so changing the 1191 behaviour ought to be less painful than for other packet types. 1193 4.6. FINs 1195 RFC 3168 is silent on whether a TCP sender can set ECT on a FIN. A 1196 FIN is considered as part of the sequence of data, and the rate of 1197 pure ACKs sent after a FIN could be controlled by a CE marking on the 1198 FIN. Therefore there is no reason not to set ECT on a FIN. 1200 4.7. RSTs 1202 RFC 3168 is silent on whether a TCP sender can set ECT on a RST. The 1203 host generating the RST message does not have an open connection 1204 after sending it (either because there was no such connection when 1205 the packet that triggered the RST message was received or because the 1206 packet that triggered the RST message also triggered the closure of 1207 the connection). 1209 Moreover, the receiver of a CE-marked RST message can either: i) 1210 accept the RST message and close the connection; ii) emit a so-called 1211 challenge ACK in response (with suitable throttling) [RFC5961] and 1212 otherwise ignore the RST (e.g. because the sequence number is in- 1213 window but not the precise number expected next); or iii) discard the 1214 RST message (e.g. because the sequence number is out-of-window). In 1215 the first two cases there is no point in echoing any CE mark received 1216 because the sender closed its connection when it sent the RST. In 1217 the third case it makes sense to discard the CE signal as well as the 1218 RST. 1220 Although a congestion response following a CE-marking on a RST does 1221 not appear to make sense, the following factors have been considered 1222 before deciding whether the sender ought to set ECT on a RST message: 1224 o As explained above, a congestion response by the sender of a CE- 1225 marked RST message is not possible; 1227 o So the only reason for the sender setting ECT on a RST would be to 1228 improve the reliability of the message's delivery; 1230 o RST messages are used to both mount and mitigate attacks: 1232 * Spoofed RST messages are used by attackers to terminate ongoing 1233 connections, although the mitigations in RFC 5961 have 1234 considerably raised the bar against off-path RST attacks; 1236 * Legitimate RST messages allow endpoints to inform their peers 1237 to eliminate existing state that correspond to non existing 1238 connections, liberating resources e.g. in DoS attacks 1239 scenarios; 1241 o AQMs are advised to disable ECN marking during persistent 1242 overload, so: 1244 * it is harder for an attacker to exploit ECN to intensify an 1245 attack; 1247 * it is harder for a legitimate user to exploit ECN to more 1248 reliably mitigate an attack 1250 o Prohibiting ECT on a RST would deny the benefit of ECN to 1251 legitimate RST messages, but not to attackers who can disregard 1252 RFCs; 1254 o If ECT were prohibited on RSTs 1256 * it would be easy for security middleboxes to discard all ECN- 1257 capable RSTs; 1259 * However, unlike a SYN flood, it is already easy for a security 1260 middlebox (or host) to distinguish a RST flood from legitimate 1261 traffic [RFC5961], and even if a some legitimate RSTs are 1262 accidentally removed as well, legitimate connections still 1263 function. 1265 So, on balance, it has been decided that it is worth experimenting 1266 with ECT on RSTs. During experiments, if the ECN capability on RSTs 1267 is found to open a vulnerability that is hard to close, this decision 1268 can be reversed, before it is specified for the standards track. 1270 4.8. Retransmitted Packets. 1272 RFC 3168 says the sender "MUST NOT" set ECT on retransmitted packets. 1273 The rationale for this consumes nearly 2 pages of RFC 3168, so the 1274 reader is referred to section 6.1.5 of RFC 3168, rather than quoting 1275 it all here. There are essentially three arguments, namely: 1276 reliability; DoS attacks; and over-reaction to congestion. We 1277 address them in order below. 1279 The reliability argument has already been addressed in Section 4.1. 1281 Protection against DoS attacks is not afforded by prohibiting ECT on 1282 retransmitted packets. An attacker can set CE on spoofed 1283 retransmissions whether or not it is prohibited by an RFC. 1284 Protection against the DoS attack described in section 6.1.5 of RFC 1285 3168 is solely afforded by the requirement that "the TCP data 1286 receiver SHOULD ignore the CE codepoint on out-of-window packets". 1287 Therefore in Section 3.2.7 the sender is allowed to set ECT on 1288 retransmitted packets, in order to reduce the chance of them being 1289 dropped. We also strengthen the receiver's requirement from "SHOULD 1290 ignore" to "MUST ignore". And we generalize the receiver's 1291 requirement to include failure of any validity check, not just out- 1292 of-window checks, in order to include the more stringent validity 1293 checks in RFC 5961 that have been developed since RFC 3168. 1295 A consequence is that, for those retransmitted packets that arrive at 1296 the receiver after the original packet has been properly received 1297 (so-called spurious retransmissions), any CE marking will be ignored. 1298 There is no problem with that because the fact that the original 1299 packet has been delivered implies that the sender's original 1300 congestion response (when it deemed the packet lost and retransmitted 1301 it) was unnecessary. 1303 Finally, the third argument is about over-reacting to congestion. 1304 The argument goes that, if a retransmitted packet is dropped, the 1305 sender will not detect it, so it will not react again to congestion 1306 (it would have reduced its congestion window already when it 1307 retransmitted the packet). Whereas, if retransmitted packets can be 1308 CE tagged instead of dropped, senders could potentially react more 1309 than once to congestion. However, we argue that it is legitimate to 1310 respond again to congestion if it still persists in subsequent round 1311 trip(s). 1313 Therefore, in all three cases, it is not incorrect to set ECT on 1314 retransmissions. 1316 5. Interaction with popular variants or derivatives of TCP 1318 The following subsections discuss any interactions between setting 1319 ECT on all all packets and using the following popular variants or 1320 derivatives of TCP: SCTP, IW10 and TFO. This section is informative 1321 not normative, because no interactions have been identified that 1322 require any change to specifications. The subsection on IW10 1323 discusses potential changes to specifications but recommends that no 1324 changes are needed. 1326 TCP variants that have been assessed and found not to interact 1327 adversely with ECT on TCP control packets are: SYN cookies (see 1328 Appendix A of [RFC4987] and section 3.1 of [RFC5562]), TCP Fast Open 1329 (TFO [RFC7413]) and L4S [I-D.briscoe-tsvwg-l4s-arch]. 1331 5.1. SCTP 1333 Stream Control Transmission Protocol (SCTP [RFC4960]) is a standards 1334 track protocol derived from TCP. SCTP currently does not include ECN 1335 support, but Appendix A of RFC 4960 broadly describes how it would be 1336 supported and a draft on the addition of ECN to SCTP has been 1337 produced [I-D.stewart-tsvwg-sctpecn]. This draft avoids setting ECT 1338 on control packets and retransmissions, closely following the 1339 arguments in RFC 3168. When ECN is finally added to SCTP, experience 1340 from experiments on adding ECN support to all TCP packets ought to be 1341 directly transferable to SCTP. 1343 5.2. IW10 1345 IW10 is an experiment to determine whether it is safe for TCP to use 1346 an initial window of 10 SMSS [RFC6928]. 1348 This subsection does not recommend any additions to the present 1349 specification in order to interwork with IW10. The specifications as 1350 they stand are safe, and there is only a corner-case with ECT on the 1351 SYN where performance could be occasionally improved, as explained 1352 below. 1354 As specified in Section 3.2.1.1, a TCP initiator can only set ECT on 1355 the SYN if it requests AccECN support. If, however, the SYN-ACK 1356 tells the initiator that the responder does not support AccECN, 1357 Section 3.2.1.1 advises the initiator to conservatively reduce its 1358 initial window to 1 SMSS because, if the SYN was CE-marked, the SYN- 1359 ACK has no way to feed that back. 1361 If the initiator implements IW10, it seems rather over-conservative 1362 to reduce IW from 10 to 1 just in case a congestion marking was 1363 missed. Nonetheless, the reduction to 1 SMSS will rarely harm 1364 performance, because: 1366 o as long as the initiator is caching failures to negotiate AccECN, 1367 subsequent attempts to access the same server will not use ECT on 1368 the SYN anyway, so there will no longer be any need to 1369 conservatively reduce IW; 1371 o currently it is not common for a TCP initiator (client) to have 1372 more than one data segment to send {ToDo: evidence/reference?} - 1373 IW10 is primarily exploited by TCP servers. 1375 If a responder receives feedback that the SYN-ACK was CE-marked, 1376 Section 3.2.2.2 mandates that it reduces its initial window to 1 1377 SMSS. When the responder also implements IW10, it is particularly 1378 important to adhere to this requirement in order to avoid overflowing 1379 a queue that is clearly already congested. 1381 5.3. TFO 1383 TCP Fast Open (TFO [RFC7413]) is an experiment to remove the round 1384 trip delay of TCP's 3-way hand-shake (3WHS). A TFO initiator caches 1385 a cookie from a previous connection with a TFO-enabled server. Then, 1386 for subsequent connections to the same server, any data included on 1387 the SYN can be passed directly to the server application, which can 1388 then return up to an initial window of response data on the SYN-ACK 1389 and on data segments straight after it, without waiting for the ACK 1390 that completes the 3WHS. 1392 The TFO experiment and the present experiment to add ECN-support for 1393 TCP control packets can be combined without altering either 1394 specification, which is justified as follows: 1396 o The handling of ECN marking on a SYN is no different whether or 1397 not it carries data. 1399 o In response to any CE-marking on the SYN-ACK, the responder adopts 1400 the normal response to congestion, as discussed in Section 7.2 of 1401 [RFC7413]. 1403 6. Security Considerations 1405 Section 3.2.6 considers the question of whether ECT on RSTs will 1406 allow RST attacks to be intensified. There are several security 1407 arguments presented in RFC 3168 for preventing the ECN marking of TCP 1408 control packets and retransmitted segments. We believe all of them 1409 have been properly addressed in Section 4, particularly Section 4.2.3 1410 and Section 4.8 on DoS attacks using spoofed ECT-marked SYNs and 1411 spoofed CE-marked retransmissions. 1413 7. IANA Considerations 1415 There are no IANA considerations in this memo. 1417 8. Acknowledgments 1419 Thanks to Mirja Kuehlewind and David Black for their useful reviews. 1421 The work of Marcelo Bagnulo has been performed in the framework of 1422 the H2020-ICT-2014-2 project 5G NORMA. His contribution reflects the 1423 consortiums view, but the consortium is not liable for any use that 1424 may be made of any of the information contained therein. 1426 9. References 1428 9.1. Normative References 1430 [I-D.ietf-tcpm-accurate-ecn] 1431 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 1432 Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- 1433 ecn-03 (work in progress), May 2017. 1435 [I-D.ietf-tsvwg-ecn-experimentation] 1436 Black, D., "Explicit Congestion Notification (ECN) 1437 Experimentation", draft-ietf-tsvwg-ecn-experimentation-05 1438 (work in progress), August 2017. 1440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1441 Requirement Levels", BCP 14, RFC 2119, 1442 DOI 10.17487/RFC2119, March 1997, 1443 . 1445 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1446 of Explicit Congestion Notification (ECN) to IP", 1447 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1448 . 1450 [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. 1451 Ramakrishnan, "Adding Explicit Congestion Notification 1452 (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, 1453 DOI 10.17487/RFC5562, June 2009, 1454 . 1456 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 1457 Robustness to Blind In-Window Attacks", RFC 5961, 1458 DOI 10.17487/RFC5961, August 2010, 1459 . 1461 9.2. Informative References 1463 [ecn-pam] Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I., 1464 Fairhurst, G., and R. Scheffenegger, "Enabling Internet- 1465 Wide Deployment of Explicit Congestion Notification", 1466 Int'l Conf. on Passive and Active Network Measurement 1467 (PAM'15) pp193-205, 2015. 1469 [ECN-PLUS] 1470 Kuzmanovic, A., "The Power of Explicit Congestion 1471 Notification", ACM SIGCOMM 35(4):61--72, 2005. 1473 [I-D.briscoe-tsvwg-ecn-l4s-id] 1474 Schepper, K., Briscoe, B., and I. Tsang, "Identifying 1475 Modified Explicit Congestion Notification (ECN) Semantics 1476 for Ultra-Low Queuing Delay", draft-briscoe-tsvwg-ecn-l4s- 1477 id-02 (work in progress), October 2016. 1479 [I-D.briscoe-tsvwg-l4s-arch] 1480 Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency, 1481 Low Loss, Scalable Throughput (L4S) Internet Service: 1482 Architecture", draft-briscoe-tsvwg-l4s-arch-02 (work in 1483 progress), March 2017. 1485 [I-D.stewart-tsvwg-sctpecn] 1486 Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream 1487 Control Transmission Protocol (SCTP)", draft-stewart- 1488 tsvwg-sctpecn-05 (work in progress), January 2014. 1490 [judd-nsdi] 1491 Judd, G., "Attaining the promise and avoiding the pitfalls 1492 of TCP in the Datacenter", USENIX Symposium on Networked 1493 Systems Design and Implementation (NSDI'15) pp.145-157, 1494 May 2015. 1496 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1497 RFC 793, DOI 10.17487/RFC0793, September 1981, 1498 . 1500 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1501 Communication Layers", STD 3, RFC 1122, 1502 DOI 10.17487/RFC1122, October 1989, 1503 . 1505 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 1506 Congestion Notification (ECN) Signaling with Nonces", 1507 RFC 3540, DOI 10.17487/RFC3540, June 2003, 1508 . 1510 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1511 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1512 . 1514 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1515 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1516 . 1518 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 1519 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 1520 . 1522 [RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding 1523 Acknowledgement Congestion Control to TCP", RFC 5690, 1524 DOI 10.17487/RFC5690, February 2010, 1525 . 1527 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1528 "Computing TCP's Retransmission Timer", RFC 6298, 1529 DOI 10.17487/RFC6298, June 2011, 1530 . 1532 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 1533 "Increasing TCP's Initial Window", RFC 6928, 1534 DOI 10.17487/RFC6928, April 2013, 1535 . 1537 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1538 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1539 . 1541 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 1542 Recommendations Regarding Active Queue Management", 1543 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 1544 . 1546 Authors' Addresses 1548 Marcelo Bagnulo 1549 Universidad Carlos III de Madrid 1550 Av. Universidad 30 1551 Leganes, Madrid 28911 1552 SPAIN 1554 Phone: 34 91 6249500 1555 Email: marcelo@it.uc3m.es 1556 URI: http://www.it.uc3m.es 1558 Bob Briscoe 1559 Simula Research Lab 1561 Email: ietf@bobbriscoe.net 1562 URI: http://bobbriscoe.net/