idnits 2.17.1 draft-ietf-tcpm-accecn-reqs-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 11, 2013) is 4089 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.briscoe-tsvwg-re-ecn-tcp' is defined on line 311, but no explicit reference was found in the text == Unused Reference: 'RFC5562' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'RFC5681' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC5690' is defined on line 331, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions M. Kuehlewind, Ed. 3 (tcpm) University of Stuttgart 4 Internet-Draft R. Scheffenegger 5 Intended status: Informational NetApp, Inc. 6 Expires: August 15, 2013 February 11, 2013 8 Problem Statement and Requirements for a More Accurate ECN Feedback 9 draft-ietf-tcpm-accecn-reqs-00 11 Abstract 13 Explicit Congestion Notification (ECN) is an IP/TCP mechanism where 14 network nodes can mark IP packets instead of dropping them to 15 indicate congestion to the end-points. An ECN-capable receiver will 16 feedback this information to the sender. ECN is specified for TCP in 17 such a way that only one feedback signal can be transmitted per 18 Round-Trip Time (RTT). Recently, new TCP mechanisms like ConEx or 19 DCTCP need more accurate ECN feedback information in the case where 20 more than one marking is received in one RTT. This documents 21 specifies requirement for different ECN feedback scheme in the TCP 22 header to provide more than one feedback signal per RTT. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 15, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 60 2. Overview ECN and ECN Nonce in IP/TCP . . . . . . . . . . . . . 4 61 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Design Approaches . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Re-use of Header Bits . . . . . . . . . . . . . . . . . . . 6 64 4.2. Use of Reserved Bits . . . . . . . . . . . . . . . . . . . 7 65 4.3. TCP Option . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 Explicit Congestion Notification (ECN) [RFC3168] is an IP/TCP 76 mechanism where network nodes can mark IP packets instead of dropping 77 them to indicate congestion to the end-points. An ECN-capable 78 receiver will feedback this information to the sender. ECN is 79 specified for TCP in such a way that only one feedback signal can be 80 transmitted per Round-Trip Time (RTT). Recently, proposed mechanisms 81 like Congestion Exposure (ConEx) or DCTCP [Ali10] need more accurate 82 ECN feedback information in case when more than one marking is 83 received in one RTT. 85 The following scenarios should briefly show where the accurate 86 feedback is needed or provides additional value: 88 A Standard (RFC5681) TCP sender that supports ConEx: 89 In this case the congestion control algorithm still ignores 90 multiple marks per RTT, while the ConEx mechanism uses the 91 extra information per RTT to re-echo more precise congestion 92 information. 94 A sender using DCTCP congestion control without ConEx: 95 The congestion control algorithm uses the extra info per RTT 96 to perform its decrease depending on the number of congestion 97 marks. 99 A sender using DCTCP congestion control and supports ConEx: 100 Both the congestion control algorithm and ConEx use the 101 accurate ECN feedback mechanism. 103 A standard TCP sender (using RFC5681 congestion control algorithm) 104 without ConEx: 105 No accurate feedback is necessary here. The congestion 106 control algorithm still react only on one signal per RTT. 107 But it is best to have one generic feedback mechanism, 108 whether it is used or not. 110 This documents ... 112 1.1. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 We use the following terminology from [RFC3168] and [RFC3540]: 120 The ECN field in the IP header: 122 CE: the Congestion Experienced codepoint, and 124 ECT(0): the first ECN-Capable Transport codepoint, and 126 ECT(1): the second ECN-Capable Transport codepoint. 128 The ECN flags in the TCP header: 130 CWR: the Congestion Window Reduced flag, 132 ECE: the ECN-Echo flag, and 134 NS: ECN Nonce Sum. 136 In this document, we will call the ECN feedback scheme as specified 137 in [RFC3168] the 'classic ECN' and our new proposal the 'more 138 accurate ECN feedback' scheme. A 'congestion mark' is defined as an 139 IP packet where the CE codepoint is set. A 'congestion event' refers 140 to one or more congestion marks belong to the same overload situation 141 in the network (usually during one RTT). 143 2. Overview ECN and ECN Nonce in IP/TCP 145 ECN requires two bits in the IP header. The ECN capability of a 146 packet is indicated when either one of the two bits is set. An ECN 147 sender can set one or the other bit to indicate an ECN-capable 148 transport (ECT) which results in two signals, ECT(0) and ECT(1). A 149 network node can set both bits simultaneously when it experiences 150 congestion. When both bits are set the packet is regarded as 151 "Congestion Experienced" (CE). 153 In the TCP header the first two bits in byte 14 are defined for the 154 use of ECN. The TCP mechanism for signaling the reception of a 155 congestion mark uses the ECN-Echo (ECE) flag in the TCP header. To 156 enable the TCP receiver to determine when to stop setting the ECN- 157 Echo flag, the CWR flag is set by the sender upon reception of the 158 feedback signal. This leads always to a full RTT of ACKs with ECE 159 set. Thus any additional CE markings arriving within this RTT can 160 not signaled back anymore. 162 ECN-Nonce [RFC3540] is an optional addition to ECN that is used to 163 protect the TCP sender against accidental or malicious concealment of 164 marked or dropped packets. This addition defines the last bit of 165 byte 13 in the TCP header as the Nonce Sum (NS) bit. With ECN-Nonce 166 a nonce sum is maintain that counts the occurrence of ECT(1) packets. 168 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 169 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 170 | | | N | C | E | U | A | P | R | S | F | 171 | Header Length | Reserved | S | W | C | R | C | S | S | Y | I | 172 | | | | R | E | G | K | H | T | N | N | 173 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 175 Figure 1: The (post-ECN Nonce) definition of the TCP header flags 177 3. Requirements 179 The requirements of the accurate ECN feedback protocol for the use of 180 e.g. Conex or DCTCP are to have a fairly accurate (not necessarily 181 perfect), timely and protected signaling. This leads to the 182 following requirements: 184 Resilience 185 The ECN feedback signal is carried within the TCP 186 acknowledgment. TCP ACKs can get lost. Moreover, delayed 187 ACK are mostly used with TCP. That means in most cases only 188 every second data packets triggers an ACK. In a high 189 congestion situation where most of the packet are marked with 190 CE, an accurate feedback mechanism must still be able to 191 signal sufficient congestion information. Thus the accurate 192 ECN feedback extension has to take delayed ACK and ACK loss 193 into account. 195 Timely 196 The CE marking is induced by a network node on the 197 transmission path and echoed by the receiver in the TCP 198 acknowledgment. Thus when this information arrives at the 199 sender, its naturally already about one RTT old. With a 200 sufficient ACK rate a further delay of a small number of ACK 201 can be tolerated but with large delays this information will 202 be out dated due to high dynamic in the network. TCP 203 congestion control which introduces parts of these dynamics 204 operates on a time scale of one RTT. Thus the congestion 205 feedback information should be delivered timely (within one 206 RTT). 208 Integrity 209 With ECN Nonce, a misbehaving receiver or network node can be 210 detected with a certain probability. As this accurate ECN 211 feedback is reusing the NS bit, it is encouraged to ensure 212 integrity as least as good as ECN Nonce. If this is not 213 possible, alternative approaches should be provided how a 214 mechanism using the accurate ECN feedback extension can re- 215 ensure integrity or give strong incentives for the receiver 216 and network node to cooperate honestly. 218 Accuracy 219 Classic ECN feeds back one congestion notification per RTT, 220 as this is supposed to be used for TCP congestion control 221 which reduces the sending rate at most once per RTT. The 222 accurate ECN feedback scheme has to ensure that if a 223 congestion events occurs at least one congestion notification 224 is echoed and received per RTT as classic ECN would do. Of 225 course, the goal of this extension is to reconstruct the 226 number of CE marking more accurately. However, a sender 227 should not assume to get the exact number of congestion 228 marking in all situations. 230 Complexity 231 Of course, the more accurate ECN feedback can also be used, 232 even if only one ECN feedback signal per RTT is need. The 233 implementation should be as simple as possible and only a 234 minimum of addition state information should be needed. A 235 proposal fulfilling this for a more accurate ECN feedback can 236 then also be the standard ECN feedback mechanism. 238 4. Design Approaches 240 4.1. Re-use of Header Bits 242 The idea is to use the ECE, CWR and NS bits for additional capability 243 negotiation during the TCP handshake exchange, and then for the more 244 accurate ECN feedback itself on subsequent packets in the flow (where 245 SYN is not set). This appraoch only provide a limited resiliency 246 against ACK lost. 248 There have been several codings proposed so far: The one bit scheme 249 sends one ECE for each CE received (+ redundancy in next ACK using 250 the CWR bit). The 3 bit counter scheme uses all three bits for 251 continuesly feeding the three most significant bits of a CE counter 252 back. The 3 bit codepoint scheme encodes either a CE counter or an 253 ECT(1) counter in 8 codepoints. 255 Discussion on ACK loss and ECN... 257 ToDo: Use of other header bit? 258 4.2. Use of Reserved Bits 260 As seen in Figure 1, there are currently three unused flag bits in 261 the TCP header. The proposed scheme could be extended by one or more 262 bits, to add higher resiliency against ACK loss. The relative gain 263 would be proportionally higher resiliency against ACK loss, while the 264 respective drawbacks would remain identical. 266 4.3. TCP Option 268 Alternatively, a new TCP option could be introduced, to help maintain 269 the accuracy, and integrity of the ECN feedback between receiver and 270 sender. Such an option could provide more information. E.g. ECN 271 for RTP/UDP provides explicit the number of ECT(0), ECT(1), CE, non- 272 ECT marked and lost packets. However, deploying new TCP options has 273 its own challenges. A separate document proposes a new TCP Option 274 for accurate ECN feedback [I-D.kuehlewind-tcpm-accurate-ecn-option]. 275 This option could be used in addition to a more accurate ECN feedback 276 scheme described here or in addition to classic ECN, when available 277 and needed. 279 5. Acknowledgements 281 6. IANA Considerations 283 This memo includes no request to IANA. 285 7. Security Considerations 287 TBD 289 8. References 291 8.1. Normative References 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, March 1997. 296 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 297 of Explicit Congestion Notification (ECN) to IP", 298 RFC 3168, September 2001. 300 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 301 Congestion Notification (ECN) Signaling with Nonces", 302 RFC 3540, June 2003. 304 8.2. Informative References 306 [Ali10] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, 307 P., Prabhakar, B., Sengupta, S., and M. Sridharan, "DCTCP: 308 Efficient Packet Transport for the Commoditized Data 309 Center", Jan 2010. 311 [I-D.briscoe-tsvwg-re-ecn-tcp] 312 Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith, 313 "Re-ECN: Adding Accountability for Causing Congestion to 314 TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-09 (work in 315 progress), October 2010. 317 [I-D.kuehlewind-tcpm-accurate-ecn-option] 318 Kuehlewind, M. and R. Scheffenegger, "Accurate ECN 319 Feedback Option in TCP", 320 draft-kuehlewind-tcpm-accurate-ecn-option-01 (work in 321 progress), July 2012. 323 [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. 324 Ramakrishnan, "Adding Explicit Congestion Notification 325 (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, 326 June 2009. 328 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 329 Control", RFC 5681, September 2009. 331 [RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding 332 Acknowledgement Congestion Control to TCP", RFC 5690, 333 February 2010. 335 Authors' Addresses 337 Mirja Kuehlewind (editor) 338 University of Stuttgart 339 Pfaffenwaldring 47 340 Stuttgart 70569 341 Germany 343 Email: mirja.kuehlewind@ikr.uni-stuttgart.de 344 Richard Scheffenegger 345 NetApp, Inc. 346 Am Euro Platz 2 347 Vienna, 1120 348 Austria 350 Phone: +43 1 3676811 3146 351 Email: rs@netapp.com