idnits 2.17.1 draft-bagnulo-tsvwg-generalized-ecn-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 122: '...an ECT codepoint MUST NOT be set in a ...' RFC 2119 keyword, line 324: '...an ECT codepoint MUST NOT be set in a ...' RFC 2119 keyword, line 336: '... at this time, "pure" ACK packets MUST...' RFC 2119 keyword, line 343: '...companying data) MUST be sent with the...' RFC 2119 keyword, line 400: '...N-capable TCP implementations MUST NOT...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2016) is 2849 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: Informational B. Briscoe 5 Expires: January 9, 2017 Simula Research Lab 6 July 8, 2016 8 Adding Explicit Congestion Notification (ECN) to TCP control packets 9 draft-bagnulo-tsvwg-generalized-ecn-01 11 Abstract 13 This documents explores the possibility of adding ECN support to TCP 14 control packets. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 9, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. The reliability argument . . . . . . . . . . . . . . . . . . 3 52 3. TCP SYNs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Pure ACKs. . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 5. Retransmitted packets. . . . . . . . . . . . . . . . . . . . 9 55 6. Window probe packets . . . . . . . . . . . . . . . . . . . . 11 56 7. Security considerations . . . . . . . . . . . . . . . . . . . 12 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 58 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 59 10. Informative References . . . . . . . . . . . . . . . . . . . 12 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 62 1. Introduction 64 RFC3168 [RFC3168] specifies the support of Explicit Congestion 65 Notification (ECN) to IP. By using the ECN capability, switches 66 performing Active Queue Management (AQM) can use ECN marks instead of 67 packets drops to signal congestion to the endpoints of a 68 communication. This results in lower packet loss and increased 69 performance. However, RFC3168 specifies the support of ECN in TCP 70 data packets, but precludes the use of ECN in TCP control packets 71 (TCP SYN, TCP SYN/ACK, pure ACKs, Window probes) and in retransmitted 72 packets. RFC 5562 [RFC5562] is an experimental extension to ECN that 73 enables the ECN support for TCP SYN/ACK packets. 75 The inability of using ECN in TCP control packets has a potential 76 harmful effect, especially in environments where ECN support is 77 pervasive. For example, [judd-nsdi] shows that in a data center 78 environment where DCTCP is used (in conjunction with ECN), the the 79 probability of being able to establish a new connection using a non- 80 ECT-marked SYN packet drops to close to 0 when there are 16 ongoing 81 TCP flows transmitting at full speed. In this particular context of 82 a datacenter using DCTCP, the issue is that the proposed AQM 83 aggressively marks packets to keep the buffer queues small and this 84 implies that non-ECT-marked packets are in turn dropped aggressively 85 as well, rendering nearly impossible to establish new connection when 86 there is ongoing traffic. 88 These limitations are not limited to the data center environment. In 89 any ECN deployment, non ECT marked packets suffer a penalty when they 90 traverse a congested bottleneck. For instance, with a drop 91 probability of 1%, 1% of connection attempts suffer a timeout before 92 the SYN is retransmitted, which is very deterimental to the 93 performance of short flows. Dropping TCP control traffic, such as 94 TCP SYNs and pure ACKs have a negative effect on the overall 95 performance of the communication, so it is beneficial to avoid it. 97 Finally, there are ongoing efforts to promote the adoption of DCTCP 98 (and similar transports) over the Internet to achieve low latency for 99 all communications [I-D.briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem]. 100 In such approach, ECN capable packets are treated more favorably, as 101 they are likely to experience less delay and lower packet drop 102 probability. Preventing TCP control packets, which are critical for 103 TCP performance, to obtain the benefits of ECN would result in 104 degraded performance. 106 However, RFC3168 does not prevents from using ECN in TCP control 107 packets lightly. It provides a number of specific reasons for each 108 packet type. In this note, we revisit each of the arguments provided 109 by RFC3168 and explore possibilities to enable the ECN capability in 110 the different packet types. We do so in the context of a data center 111 network and in the context of the public Internet. 113 2. The reliability argument 115 While for each type of packet RFC 3168 provides a set of specific 116 arguments for preventing their marking, RFC3168 presents the reliable 117 delivery of the congestion signal as an overarching argument that 118 needs to be consider when trying to enable the ECT marking of TCP 119 control packets. In particular, Section 5.2 of RFC3168 states: 121 To ensure the reliable delivery of the congestion indication of 122 the CE codepoint, an ECT codepoint MUST NOT be set in a packet 123 unless the loss of that packet in the network would be detected by 124 the end nodes and interpreted as an indication of congestion. 126 We believe this argument is overly conservative. The overall 127 principle that should determine the level of reliability required for 128 ECN capable packets should be the one of "do not harm". Reliable 129 delivery of the CE codepoint is indeed paramount but the level of 130 reliability required should be the one of the original congestion 131 signal (i.e. the detection of the loss of the original packet). In 132 other words, the situation without ECN is that when a packet is to be 133 transmitted through a congested link, the packet may be dropped and 134 that is the congestion signal sent to the endpoint. When ECN is 135 introduced, the reliability of the delivery of the congestion signal 136 should be no worse than without ECN. In particular, setting the CE 137 codepoint in the very same packet seem to fulfill this criteria, 138 since either the packet is delivered and the CE codepoint signal is 139 delivered to the endpoint, or the packet is dropped, so the original 140 congestion signal through the packet loss is delivered to the 141 endpoint. Requiring more than this implies that the ECN congestion 142 signal is delivered more reliably than the current situation, which 143 is not a bad thing per se, but, as we describe in this memo, it 144 results in performance penalties that should be reconsidered in the 145 view of current deployments. 147 In addition, the reliability of the delivery of the congestion signal 148 is used an argument for not setting the ECT codepoint in TCP control 149 packets, which effectively reduced the reliability of the 150 transmission of these TCP control packets. There is the then a 151 tradeoff between the reliability of the delivery of the congestion 152 signal and the reliability of the delivery of TCP control packets. 153 As currently specified, ECN adoption implies an increased reliability 154 of the ECN congestion signal and a decrease in the reliability in the 155 TCP control packets. We believe that it is possible and desirable to 156 restore the tradeoff existent in non ECN capable networks in terms of 157 reliability, where the congestion signal delivery is as reliable as 158 in a non ECN capable network and so it is the delivery of TCP control 159 packets. 161 3. TCP SYNs 163 We next describe he arguments exhibited by current specification for 164 precluding the ECT marking of SYN packets. 166 In addition to the reliability argument above, RFC 5562 presents two 167 arguments against ECT marking of SYN packets (cited verbatim): 169 There are several reasons why an ECN-Capable codepoint must not be 170 set in the IP header of the initiating TCP SYN packet. First, 171 when the TCP SYN packet is sent, there are no guarantees that the 172 other TCP endpoint (node B in Figure 2) is ECN-Capable, or that it 173 would be able to understand and react if the ECN CE codepoint was 174 set by a congested router. 176 Second, the ECN-Capable codepoint in TCP SYN packets could be 177 misused by malicious clients to "improve" the well-known TCP SYN 178 attack. By setting an ECN-Capable codepoint in TCP SYN packets, a 179 malicious host might be able to inject a large number of TCP SYN 180 packets through a potentially congested ECN-enabled router, 181 congesting it even further. 183 We next go through all the arguments stated above to enable ECT 184 marking of SYN packets. 186 Argument 1: Unknown ECN capability capability at the responder. The 187 initiator does not know whether the responder supports ECN and in 188 particular, the initiator does not know if the responder supports ECT 189 marked SYNs. 191 In the DC context, this argument does not hold (at least in single 192 tenant DCs, possibly in multi-tenant DCs, if we assume that each 193 tenant mostly communicates with its own VMs). The DC is a much more 194 controlled environment than the public Internet, so the server's 195 support of ECN can be guaranteed administratively i.e. the manager of 196 the DC makes sure that the servers support ECN and in particular ECT 197 marked SYN packets. 199 In the public Internet context, it cannot be assumed that all servers 200 support ECN, and much less that they support ECT marked SYN packets. 201 When sending an ECT marked SYN to a legacy responder (i.e. a 202 responder that does not support ECT marked SYNs), different 203 behaviours are possible. 205 The responder may drop the SYN (either silently or by sending a RST) 206 or may reply with a non ECT marked SYN/ACK. If it is the latter, 207 then this is a non-issue (the second issue presented next still 208 applies though). If it is the former, then the initiator will have 209 to retransmit the SYN (without the ECT mark). Depending how extended 210 is this behaviour, this can reduce significantly the benefits of 211 adding ECT capability to the SYN or even be detrimental for the 212 performance. According to [ecn-pam], out of the top 1M Alexa web 213 sites, 0,82% of IPv4 sites and 0,61% of IPv6 sites fail to establish 214 a connection when they receive a TCP SYN with any ECN codepoint set. 216 If based on this data, we conclude that the fraction of fraction of 217 servers that discard the ECT marked SYN is a non negligible, further 218 options depend on whether they silently discard it or they send a RST 219 back. If they send a RST back, the initiator can then send a non ECT 220 marked SYN. In this case the penalty would be an extra RTT, which 221 may or may not be acceptable, depending on the fraction of servers 222 that behaves like this. If the server silently discard the ECT 223 marked SYN, then the initiator needs to wait for the retransmission 224 timer to expire and retransmit a non-ECT marked SYN. This is a high 225 penalty. If this is the case, one option, would be to first send an 226 ECT marked SYN and then a non-ECT marked SYN (possibly with a small 227 delay between them) and establish the ECT capable connection if the 228 former is replied. But it is questionable whether the level of 229 failure of ECT on SYNs warrants this, particularly given failures 230 could reduce if ECN on SYNs is standardized. 232 Argument 2: Loss of congestion notification in the SYN packet due to 233 lack of support from the responder. If the ECT marked SYN packet is 234 tagged as CE by a router along the path and the server does not 235 support ECT marked SYN packets, even if the server replies with a 236 SYN/ACK, the congestion information would be lost. 238 The accurate ECN (AccECN) proposal [I-D.ietf-tcpm-accurate-ecn] 239 suggests a two-pringed solutions to this problem. First AccECN 240 provides a way for the responder to feedback whether there was CE on 241 the SYN, and second AccECN introduces a different combination of TCP 242 header flags on the SYN/ACK so that the initiator knows whether or 243 not the responder supports AccECN. Then if the responder does 244 indicate that it supports AccECN the initiator can be sure that, if 245 there is no CE feedback on the SYNACK, then there really was no CE on 246 the SYN. 248 If the responder's SYN/ACK shows that it does not support AccECN, the 249 initiator can take a conservative approach and assume the SYN was 250 marked with CE and reduce its initial window. However, the initiator 251 knows that congestion is not serious, because both the SYN and the 252 SYN/ACK were delivered through the network. Therefore congestion is 253 not serious enough for a router to have had to turn off ECN. 254 Therefore, even a conservative initiator would not have to reduce its 255 initial window as much as it would in response to a timeout following 256 no response to its SYN. 258 Nonetheless, even a slight conservative reduction in initial window 259 might be a significant penalty, especially in the early days of 260 deployment, when little support for ECT SYN packets will be 261 available. This could be mitigated by caching previous experience of 262 which servers support AccECN. 264 Argument 3: DoS attacks. There are two possible DoS attacks involved 265 in the text contained in RFC3168. On one hand, the mention about 266 improving the well-known TCP SYN attack. The reference to the TCP 267 SYN attack we interpret it as a reference to the TCP SYN flood attack 268 (see https://en.wikipedia.org/wiki/SYN_flood). This attack is 269 addressed to the responder endpoint of the connection. The argument 270 is basically, because SYN can be used to launch attacks, their 271 transmission should not be more reliable. While it is true that SYNs 272 can be used to launch attacks, it is also true that SYNs are 273 fundamental for legitimate communications, so the argument for 274 increasing reliability of legitimate communications should take 275 precedence. On the other hand in the RFC3168 refers about ECN 276 capable SYN packets to congest further a bottleneck. It is not clear 277 why a TCP SYN packet is worse than any other packet in this respect. 278 In any case, section 7 of RFC3168 already provides the means to 279 address this concern, as it reads: 281 First, ECN-Capable routers will only mark packets (as opposed to 282 dropping them) when the packet marking rate is reasonably low. 283 During periods where the average queue size exceeds an upper 284 threshold, and therefore the potential packet marking rate would 285 be high, our recommendation is that routers drop packets rather 286 then set the CE codepoint in packet headers. 288 Safe deployment of ECN requires that network devices drop 289 excessive traffic, even when marked as originating from an ECN- 290 capable transport. This is a necessary safety precaution 291 because:.. 293 Alternative behaviour. If we were to allow setting the ECT codepoint 294 in the SYN packets, we need to define how it would behave. 296 One challenge is to support legacy ECN responders that do not support 297 ECT marked SYNs but do support ECN. 299 One possible behaviour could be something along these lines. The SYN 300 packet will carry the ECT(1) bit set as well as the ECE and CWR bits 301 set. This is needed to support legacy ECN responders that would 302 ignore the ECT bit, but properly process the ECN support negotiation 303 using the ECE and CWR flags. Routers can then set the CE bit in the 304 SYN. 306 If the responder receives a SYN with ECT(1), ECE and CWR bits set, it 307 replies with a SYN/ACK that includes ECT(1) bit set. Because the 308 ECT(1) bit is set, (and the CWR bit is not set) the initiator can 309 realize that the responder supports ECN and also ECT marked SYNs. 311 If the responder receives a SYN with ECT(1), ECE, CWR and CE bits 312 set, it replies with a SYN/ACK that includes the ECT(1) and the ECE 313 bits set. Because the ECT(1) bit is set (and the CWR bit is not 314 set), the initiator can realize that the ECE bit means that the CE 315 bit was set in the SYN and then can react accordingly. The reaction 316 to the ECE bit is then to halve the initial CWND for the connection. 318 4. Pure ACKs. 320 RFC3168 exposes the following arguments for not allowing the ECT 321 marking of pure ACKs. In section 5.2 it reads: 323 To ensure the reliable delivery of the congestion indication of 324 the CE codepoint, an ECT codepoint MUST NOT be set in a packet 325 unless the loss of that packet in the network would be detected by 326 the end nodes and interpreted as an indication of congestion. 328 Transport protocols such as TCP do not necessarily detect all 329 packet drops, such as the drop of a "pure" ACK packet; for 330 example, TCP does not reduce the arrival rate of subsequent ACK 331 packets in response to an earlier dropped ACK packet. Any 332 proposal for extending ECN- Capability to such packets would have 333 to address issues such as the case of an ACK packet that was 334 marked with the CE codepoint but was later dropped in the network. 335 We believe that this aspect is still the subject of research, so 336 this document specifies that at this time, "pure" ACK packets MUST 337 NOT indicate ECN-Capability. 339 Later on, in section 6.1.4 it reads: 341 For the current generation of TCP congestion control algorithms, 342 pure acknowledgement packets (e.g., packets that do not contain 343 any accompanying data) MUST be sent with the not-ECT codepoint. 344 Current TCP receivers have no mechanisms for reducing traffic on 345 the ACK-path in response to congestion notification. Mechanisms 346 for responding to congestion on the ACK-path are areas for current 347 and future research. (One simple possibility would be for the 348 sender to reduce its congestion window when it receives a pure ACK 349 packet with the CE codepoint set). For current TCP 350 implementations, a single dropped ACK generally has only a very 351 small effect on the TCP's sending rate. 353 We next address each of the arguments presented above. 355 The first argument is about lack of reliability while conveying 356 congestion notification information when carried in pure ACKs. This 357 is the specific instance for the pure ACK messages of the reliability 358 argument discussed in Section 2. In some cases, the loss of pure 359 ACKs is not detected by the endpoints, loosing the congestion 360 notification information indadvertedly if it was to be carried in 361 those packets. As we argued before, the bar for deciding if a packet 362 can be marked with the ECT codepoint i.e. if it is suitable for 363 carrying congestion notification information is that the congestion 364 signal communication should be as reliable as dropping the packet. 365 After all, the alternative of setting the CE bit in the packet is 366 dropping the packet. So, the question is whether carrying congestion 367 information in a pure ACK conveys the congestion information as 368 reliably as when the pure ACK is dropped and it is obvious that the 369 answer to that question is clearly yes. If the pure ACK carrying the 370 ECT and the CE bits set is later dropped by the network, it will be 371 essentially falling back to the use of drop as congestion signal. 373 The second argument exhibited in RFC3168 is the lack of means in the 374 sender of the pure ACKs to reduce the load that is creating the 375 congestion. Again, marking the pure ACKs with the ECT codepoint and 376 allowing them to carry congestion notification information would be 377 no worse than not doing so from this perspective (and it would be 378 much more detrimental form the overall performance perspective). The 379 sender of the pure ACKs will receive the echo of the congestion 380 notification and it may be able to reduce the CWND of the connection. 382 If it happens to be only sending pure ACKs and no data and it can 383 react reducing the rate at which data is being sent, it would not be 384 worse in terms of congestion than in the case that the pure ACK is 385 dropped. 387 So, overall, we believe that in terms of conveying and reacting to 388 congestion, allowing to set the ECT (and the CE) flags in the pure 389 ACKs is not worse than not doing so (and dropping the pure ACK), but 390 in terms of performance, not ECT marking the pure ACKs is certainly 391 detrimental. 393 5. Retransmitted packets. 395 RFC3168 does not allow setting the ECT codepoint in retransmitted 396 packets. The arguments presented in the specification for supporting 397 this design choice are the following ones (the text is quite long, 398 not sure if we should keep it all): 400 This document specifies ECN-capable TCP implementations MUST NOT 401 set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for 402 retransmitted data packets, and that the TCP data receiver SHOULD 403 ignore the ECN field on arriving data packets that are outside of 404 the receiver's current window. This is for greater security 405 against denial-of-service attacks, as well as for robustness of 406 the ECN congestion indication with packets that are dropped later 407 in the network. 409 First, we note that if the TCP sender were to set an ECT codepoint 410 on a retransmitted packet, then if an unnecessarily-retransmitted 411 packet was later dropped in the network, the end nodes would never 412 receive the indication of congestion from the router setting the 413 CE codepoint. Thus, setting an ECT codepoint on retransmitted 414 data packets is not consistent with the robust delivery of the 415 congestion indication even for packets that are later dropped in 416 the network. 418 In addition, an attacker capable of spoofing the IP source address 419 of the TCP sender could send data packets with arbitrary sequence 420 numbers, with the CE codepoint set in the IP header. On receiving 421 this spoofed data packet, the TCP data receiver would determine 422 that the data does not lie in the current receive window, and 423 return a duplicate acknowledgement. We define an out-of-window 424 packet at the TCP data receiver as a data packet that lies outside 425 the receiver's current window. On receiving an out-of-window 426 packet, the TCP data receiver has to decide whether or not to 427 treat the CE codepoint in the packet header as a valid indication 428 of congestion, and therefore whether to return ECN-Echo 429 indications to the TCP data sender. If the TCP data receiver 430 ignored the CE codepoint in an out-of-window packet, then the TCP 431 data sender would not receive this possibly- legitimate indication 432 of congestion from the network, resulting in a violation of end- 433 to-end congestion control. On the other hand, if the TCP data 434 receiver honors the CE indication in the out-of-window packet, and 435 reports the indication of congestion to the TCP data sender, then 436 the malicious node that created the spoofed, out-of- window packet 437 has successfully "attacked" the TCP connection by forcing the data 438 sender to unnecessarily reduce (halve) its congestion window. To 439 prevent such a denial-of-service attack, we specify that a 440 legitimate TCP data sender MUST NOT set an ECT codepoint on 441 retransmitted data packets, and that the TCP data receiver SHOULD 442 ignore the CE codepoint on out-of-window packets. 444 One drawback of not setting ECT(0) or ECT(1) on retransmitted 445 packets is that it denies ECN protection for retransmitted 446 packets. However, for an ECN-capable TCP connection in a fully- 447 ECN-capable environment with mild congestion, packets should 448 rarely be dropped due to congestion in the first place, and so 449 instances of retransmitted packets should rarely arise. If 450 packets are being retransmitted, then there are already packet 451 losses (from corruption or from congestion) that ECN has been 452 unable to prevent. 454 We note that if the router sets the CE codepoint for an ECN- 455 capable data packet within a TCP connection, then the TCP 456 connection is guaranteed to receive that indication of congestion, 457 or to receive some other indication of congestion within the same 458 window of data, even if this packet is dropped or reordered in the 459 network. We consider two cases, when the packet is later 460 retransmitted, and when the packet is not later retransmitted. 462 In the first case, if the packet is either dropped or delayed, and 463 at some point retransmitted by the data sender, then the 464 retransmission is a result of a Fast Retransmit or a Retransmit 465 Timeout for either that packet or for some prior packet in the 466 same window of data. In this case, because the data sender 467 already has retransmitted this packet, we know that the data 468 sender has already responded to an indication of congestion for 469 some packet within the same window of data as the original packet. 470 Thus, even if the first transmission of the packet is dropped in 471 the network, or is delayed, if it had the CE codepoint set, and is 472 later ignored by the data receiver as an out- of-window packet, 473 this is not a problem, because the sender has already responded to 474 an indication of congestion for that window of data. 476 In the second case, if the packet is never retransmitted by the 477 data sender, then this data packet is the only copy of this data 478 received by the data receiver, and therefore arrives at the data 479 receiver as an in-window packet, regardless of how much the packet 480 might be delayed or reordered. In this case, if the CE codepoint 481 is set on the packet within the network, this will be treated by 482 the data receiver as a valid indication of congestion. 484 There are essentially three arguments for not ECT marking 485 retransmitted packets, namely, reliability, DoS attacks and over- 486 reaction to congestion. We address all of them next in order. 488 About reliability, as described in Section 2, we believe that the bar 489 should be that the congestion signal should be delivered as reliably 490 as if it was a packet drop. So, if a retransmitted packet is dropped 491 and this goes by unnoticed by the receiver, then the congestion 492 signal expressed as a drop would be lost. The same applies to the 493 congestion signal resulting from marking with ECT and CE the very 494 same retransmitted packet which later is dropped. 496 About the possibility of DoS attacks, the protection against the DoS 497 attack does not result from not allowing retransmitted packets to be 498 ECT marked. If an attacker decided to launch such an attack, it 499 would craft the packet with the ECT codepoint set. Effectively, the 500 protection against the described DoS attack comes from the 501 requirement that the receiver should not ignore the CE codepoint in 502 out-of-window packets. We proposed to allow ECT marking of 503 retransmitted packets, in order reduces the chances of it being 504 dropped, but keep the requirement to ignore the CE codepoint in out- 505 of-window packets. 507 Finally, the third argument is about over-reacting to congestion. 508 Basically, if the retransmitted packet is dropped, the sender will 509 not react again to congestion (it has reacted already when it 510 generated the retransmitted packet). If the retransmitted packet is 511 CE tagged instead of dropped, then the congestion signal will arrive 512 again to the sender who could potentially react again to congestion. 513 However, this should not happen as RFC3168 imposes the condition that 514 a sender must only react once per window to the congestion signal and 515 this should not be an exception to this rule. 517 6. Window probe packets 519 RFC3168 presents only the reliability argument for preventing setting 520 the ECT codepoint in Window Probe packets. Specifically, it states: 522 When the TCP data receiver advertises a zero window, the TCP data 523 sender sends window probes to determine if the receiver's window 524 has increased. Window probe packets do not contain any user data 525 except for the sequence number, which is a byte. If a window 526 probe packet is dropped in the network, this loss is not detected 527 by the receiver. Therefore, the TCP data sender MUST NOT set 528 either an ECT codepoint or the CWR bit on window probe packets. 530 However, because window probes use exact sequence numbers, they 531 cannot be easily spoofed in denial-of-service attacks. Therefore, 532 if a window probe arrives with the CE codepoint set, then the 533 receiver SHOULD respond to the ECN indications. 535 The reliability argument has been addressed in Section 2. dropping 536 the window probe message in the case the conditions for the Silly 537 Window Syndrome are on, basically implies that the sender will be 538 stalled until the new Window Probe message reaches the receiver, 539 which agains results in a performance penalty. 541 On the bright side, receivers should respond to ECN messages in these 542 packets, so changing the behaviour should be less painful than for 543 other packet types. 545 7. Security considerations 547 TBD, not sure if there is any. 549 8. IANA Considerations 551 There are no IANA considerations in this memo. 553 9. Acknowledgments 555 TBD 557 10. Informative References 559 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 560 of Explicit Congestion Notification (ECN) to IP", 561 RFC 3168, DOI 10.17487/RFC3168, September 2001, 562 . 564 [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. 565 Ramakrishnan, "Adding Explicit Congestion Notification 566 (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, 567 DOI 10.17487/RFC5562, June 2009, 568 . 570 [I-D.briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem] 571 Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency, 572 Low Loss, Scalable Throughput (L4S) Internet Service: 573 Problem Statement", draft-briscoe-tsvwg-aqm-tcpm-rmcat- 574 l4s-problem-02 (work in progress), July 2016. 576 [I-D.ietf-tcpm-accurate-ecn] 577 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 578 Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- 579 ecn-01 (work in progress), June 2016. 581 [judd-nsdi] 582 Judd, G., "Attaining the promise and avoiding the pitfalls 583 of TCP in the Datacenter", NSDI 2015, 2015. 585 [ecn-pam] Brian, B., Mirja, M., Damiano, D., Iain, I., Gorry, G., 586 and R. Richard, "Enabling Internet-Wide Deployment of 587 Explicit Congestion Notification", PAM 2015, 2015. 589 Authors' Addresses 591 Marcelo Bagnulo 592 Universidad Carlos III de Madrid 593 Av. Universidad 30 594 Leganes, Madrid 28911 595 SPAIN 597 Phone: 34 91 6249500 598 Email: marcelo@it.uc3m.es 599 URI: http://www.it.uc3m.es 601 Bob Briscoe 602 Simula Research Lab 604 Email: ietf@bobbriscoe.net 605 URI: http://bobbriscoe.net/