idnits 2.17.1 draft-kuehlewind-tcpm-ecn-fallback-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 202: '...e probe segments SHOULD be sent. Othe...' RFC 2119 keyword, line 211: '... The receiver MUST, however, still s...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2013) is 3878 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM Working Group M. Kuehlewind 3 Internet-Draft University of Stuttgart 4 Intended status: Experimental B. Trammell 5 Expires: March 14, 2014 ETH Zurich 6 September 10, 2013 8 A Mechanism for ECN Path Probing and Fallback 9 draft-kuehlewind-tcpm-ecn-fallback-01.txt 11 Abstract 13 Explicit Congestion Notification (ECN) is a TCP/IP extension that is 14 widely implemented but hardly used due to the perceived unusablilty 15 of ECN on many paths through the Internet caused by ECN-ignorant 16 routers and middleboxes. This document specifies an ECN probing and 17 fall-back mechanism in case ECN has be successfully negotiated 18 between two connection endpoints, but might not be usable on the 19 path. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 14, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 The deployment of Explicit Congestion Notification (ECN) [RFC3168] 56 and AQM would arguably improve end-to-end performance in the 57 Internet, by providing a congestion signal to the transport layer 58 without relying on queue tail drop and packet loss. However, though 59 ECN has been standardized since 2000, implementation and deployment 60 have lagged significantly, in part due to the perceived unusablilty 61 of ECN on many paths through the Internet caused by ECN-ignorant 62 routers and middleboxes. 64 Recent research by the authors [KuNeTr13] has shown accelerating 65 deployment of ECN-capable servers in the Internet, due to the 66 deployment of TCP stacks for which ECN is enabled by default. In 67 addition, ECN is usable end-to-end on the vast majority of paths 68 measured in this study: that is, a Congestion Experienced mark will 69 cause a ECN Echo on the associated ACK. However, there still exist a 70 non-negligible number of paths on which a successfully negotiated 71 usage of ECN will not result in a connection on which congestion will 72 be correctly echoed, or worse, leads to the loss of packets with CE 73 or ECE set. 75 This document presents an experimental, in-band, runtime method for 76 determining the usability of ECN by a given traffic flow, based on 77 the active measurement method described in [KuNeTr13]. If ECN is 78 successfully negotiated but found by this method to be unusable, it 79 can be disabled on subsequent packets in the flow in order to avoid 80 connectivity problems caused by ECN-unusability on the path. 82 2. ECN Path Capability Probing 84 A TCP sender can determine whether or not its path to the receiver is 85 usable for ECN using the procedure detailed below. 87 1. The sender attempts to negotiate ECN usage as per Section 6.1.1 88 of [RFC3168]. If ECN is not successfully negotiated, the 89 procedure ends, and ECN is not used for the duration of the 90 connection. 92 2. The sender disables the normal usage of ECN for the duration of 93 the procedure, as the ECN codepoints are used for path probing. 94 This means all segments are sent with the Non-ECN-Capable 95 codepoint during this procedure unless otherwise stated. 96 Moreover, the sender will only take loss as a congestion signal 97 and will not react with window reductions to the ECN-Echo (ECE) 98 feedback signal from the receiver during this procedure. 100 3. The sender sets the Non-ECN-Capable codepoint in the IP header 101 until it has completed sending the first N data segments, where N 102 is the size of the initial congestion window. Loss is used to 103 discover congestion for these segments. 105 4. The next three data segments sent consist of the "CE probe": 106 these three segments are sent with the Congestion Experienced 107 codepoint set. 109 5. If all three of the CE probe segments are lost and must be 110 retransmitted, the path is deemed not ECN-usable and the sender 111 falls back as in Section 3. 113 6. If the ECE flag is not set on the ACK segment(s) sent by the 114 receiver acknowledging the CE probe segments, the path may or may 115 not be usable, as that there might be middleboxes/gateways that 116 clear CE on segments from end hosts, because they assume that 117 congestion can not have occurred up to this point on the path. 118 In this case, the sender may continue using ECN, because while it 119 may not work for detecting congestion, the use of ECN does not 120 negatively affect connectivity. 122 7. While the sender does not reduce the congestion window for the 123 ECE ACKS acknowledging the the CE probe segments, it does set CWR 124 on the subsequent segment sent. 126 8. If no fallback has occurred by the time the ACK of the final CE 127 probe segment is received, the path is deemed ECN usable, and the 128 sender ends the probing procedure and proceeds to use ECN 129 normally as in [RFC3168]. 131 The operation of this procedure on an ECN-usable path, with an 132 initial window size of 3, bulk data transfer initiated by the sender, 133 where the receiver does not perform probing, is shown in Figure 1. 135 Sender Receiver 136 | | 137 |----SYN ECE CWR----------->| connection 138 |<-----------SYN ACK ECE----| establishment 139 |----ACK------------------->| 140 | | 141 |----data 0---------------->| initial window 142 |<------------ECT0 ACK 1----| transmission 143 |----data 1---------------->| 144 |----data 2---------------->| 145 |<------------ECT0 ACK 3----| 146 | | 147 |----data 3 CE------------->| CE probe 148 |----data 4 CE------------->| 149 |----data 5 CE------------->| 150 |----data 6 --------------->| 151 |<--------ECT0 ECE ACK 7----| CE probe ACK: ECN OK 152 | | 153 |----data 7 ECT0 CWR------>| CE probe CWR 154 |----data 8 ECT0---------->| and transition to 155 |----data 9 ECT0---------->| normal ECN usage 157 Figure 1: CE probing on ECN-usable path 159 Conversely, the operation of the probe and fallback procedure on an 160 ECN-unusable path with an initial window size of 3, bulk data 161 transfer initiated by the sender, where the receiver does not perform 162 probing, is shown in Figure 2. 164 Sender Receiver 165 | | 166 |----SYN ECE CWR----------->| connection 167 |<-----------SYN ACK ECE----| establishment 168 |----ACK------------------->| 169 | | 170 |----data 0---------------->| initial window 171 |<-----------------ACK 1----| transmission 172 |----data 1---------------->| 173 |----data 2---------------->| 174 |<-----------------ACK 3----| 175 | | 176 |----data 3 CE----X | CE probe 177 |----data 4 CE----X | (blocked) 178 |----data 5 CE----X | 179 |----data 6 --------------->| 180 |<-----------------ACK 3----| dupack 181 |----data 7 --------------->| 182 |----data 8---------------->| 183 |<-----------------ACK 3----| dupack 184 | | 185 |----data 3---------------->| retransmit without CE 186 |<-----------------ACK 4----| 187 |----data 4---------------->| 188 |<-----------------ACK 5----| 189 |----data 5---------------->| 190 |<-----------------ACK 9----| and fallback (no ECN) 191 |----data 9---------------->| 193 Figure 2: Fallback on ECN-unusable path 195 As the probing begins after all the segments in the initial 196 congestion window have been sent, it requires more than an initial 197 congestion window plus 6 segments (3 CE probe + 3 duplicated ACKs) of 198 available data to send. TCP implementations can use socket send 199 buffer occupancy as a signal as to whether sufficient data is 200 available to use the probing procedure. If enough data is already in 201 the buffer by the time the initial congestion window is sent, then 202 the probe segments SHOULD be sent. Otherwise, the implementation can 203 use additional heuristics, outside the scope of this document to 204 define, to determine if significant data is likely to be available. 206 3. ECN Fallback 208 If ECN is found to be unusable on a given flow by path capability 209 probing as in Section 2 above, the sender simply stops setting any 210 ECN-Capable-Transport codepoint on subsequent packets in the flow. 211 The receiver MUST, however, still set ECE on any ACK for a packet 212 with CE set. Note that this behavior is consistent with section 213 6.1.1 of [RFC3168]. 215 A sender may keep a cache of paths found to be unusable for ECN and 216 disable ECN for subsequent connections on a per-destination basis. 217 In this case, the reciever should periodically (i.e., on the order of 218 hours or days) expire these cache entries to cause re-probing to 219 occur in order to account for routing changes in the network. 221 [EDITOR'S NOTE: what to do on RTO?] 223 4. Discussion 225 [EDITOR'S NOTE: the general case of this algorithm is J ECT segments 226 followed by K CE segments; we chose (J,K) = (0,3). We should justify 227 this choice.] 229 [EDITOR'S NOTE: need to think about how this would interact with 230 conex; an analysis comparing the delay caused by path probing as 231 opposed to the delay caused by ECN failure would be interesting.] 233 [EDITOR'S NOTE: initial implementation results go here?.] 235 5. Security Considerations 237 [FIXME: we'll have to explore attacks against this mechanism which 238 could affect network or connection stability, so the following is 239 wrong...] 241 This document has no security considerations. 243 6. IANA Considerations 245 This document has no IANA considerations. 247 7. Acknowledgements 249 Thanks to Michael Welzl and Richard Scheffenegger for the comments 250 and discussions. This work is partially materially supported by the 251 European Commission under grant agreement FP7-ICT-318627 mPlane. 253 8. References 254 8.1. Normative References 256 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 257 of Explicit Congestion Notification (ECN) to IP", RFC 258 3168, September 2001. 260 8.2. Informative References 262 [KuNeTr13] 263 Kuehlewind, M., Neuner, S., and B. Trammell, "On the state 264 of ECN and TCP Options on the Internet", Mar 2013. 266 (In LNCS 7799, Proceedings of PAM 2013, Hong Kong) 268 Authors' Addresses 270 Mirja Kuehlewind 271 University of Stuttgart 272 Pfaffenwaldring 47 273 70569 Stuttgart 274 Germany 276 Email: mirja.kuehlewind@ikr.uni-stuttgart.de 278 Brian Trammell 279 Swiss Federal Institute of Technology Zurich 280 Gloriastrasse 35 281 8092 Zurich 282 Switzerland 284 Phone: +41 44 632 70 13 285 Email: trammell@tik.ee.ethz.ch