idnits 2.17.1 draft-kuehlewind-tcpm-accurate-ecn-option-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2012) is 4305 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.briscoe-tsvwg-re-ecn-tcp' is defined on line 247, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tcpm M. Kuehlewind, Ed. 3 Internet-Draft University of Stuttgart 4 Intended status: Experimental R. Scheffenegger 5 Expires: January 14, 2013 NetApp, Inc. 6 July 13, 2012 8 Accurate ECN Feedback Option in TCP 9 draft-kuehlewind-tcpm-accurate-ecn-option-01 11 Abstract 13 This document specifies an TCP option to get accurate Explicit 14 Congestion Notification (ECN) feedback from the receiver. ECN is an 15 IP/TCP mechanism where network nodes can mark IP packets instead of 16 dropping them to indicate congestion to the end-points. An ECN- 17 capable receiver will feedback this information to the sender. ECN 18 is specified for TCP in such a way that only one feedback signal can 19 be transmitted per Round-Trip Time (RTT). Recently new TCP 20 mechanisms like ConEx or DCTCP need more accurate feedback 21 information in the case where more than one marking is received in 22 one RTT. This TCP extension can be used in addition to the classic 23 ECN as well as with a more accurate ECN scheme recently proposed 24 which reuses the ECN bit in the TCP header. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 14, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Overview ECN and ECN Nonce in IP . . . . . . . . . . . . . 3 62 1.2. Requirements Language . . . . . . . . . . . . . . . . . . . 3 63 2. Negotiation of Accurate ECN feedback . . . . . . . . . . . . . 4 64 3. Accurate ECN (AccECN) feedback Option Specification . . . . . . 5 65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 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 feedback information in case when more than one marking is received 83 in one RTT. 85 This documents specifies an TCP option to provide more than one ECN 86 feedback signal per RTT. This modification does not obsolete 87 [RFC3168]. This TCP extension can be used in addition to the classic 88 ECN as well as in addition to more accurate ECN scheme recently 89 proposed which reuses the ECN bits in the TCP header for the same 90 purpose than this extension --- more accurate ECN feedback (see 91 [I-D.kuehlewind-conex-accurate-ecn]). Note that a new TCP extension 92 can experience deployment problems by middleboxes dropping unknown 93 options. Thus the ECN feedback in the TCP header is still needed to 94 ensure ECN feedback. Moreover, this option will increase the header 95 length for all kind of TCP packets which can cause additional load in 96 case of severe congestion (on the feedback channel). 98 1.1. Overview ECN and ECN Nonce in IP 100 ECN requires two bits in the IP header. The ECN capability of a 101 packet is indicated, when either one of the two bits is set. An ECN 102 sender can set one or the other bit to indicate an ECN-capable 103 transport (ETC) which results in two signals --- ECT(0) and 104 respectively ECT(1). A network node can set both bits simultaneously 105 when it experiences congestion. When both bits are set the packets 106 is regarded as "Congestion Experienced" (CE). 108 ECN-Nonce [RFC3540] is an optional addition to ECN that is used to 109 protects the TCP sender against accidental or malicious concealment 110 of marked or dropped packets. With ECN-Nonce a nonce sum is maintain 111 that counts the occurrence of ECT(1) packets. 113 1.2. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 We use the following terminology from [RFC3168] and [RFC3540]: 121 The ECN field in the IP header: 123 CE: the Congestion Experienced codepoint; and 125 ECT(0)/ECT(1): either one of the two ECN-Capable Transport 126 codepoints. 128 In this document, we will call the ECN feedback scheme as specified 129 in [RFC3168] the 'classic ECN'. A 'congestion mark' is defined as an 130 IP packet where the CE codepoint is set. 132 2. Negotiation of Accurate ECN feedback 134 As there is only limited space in the TCP Options, particularly 135 during the initial three-way handshake, an abbreviated Option is used 136 to negotiate for Accurate ECN feedback. This option also initiates 137 all counters to an initial value of zero at the receiving side. 139 TCP Accurate ECN Option Negotiation: 141 Kind: TBD 143 Length: 2 bytes 145 +------+-----+ 146 | Kind | 2 | 147 +------+-----+ 148 1 1 150 Figure 1: Accurate ECN feedback TCP option negotiation 152 This abbreviated option is only valid in a or 153 segment, during a three way handshake. The negotiation follows the 154 same procedure as with other TCP options, i.e. SACK. A TCP sender 155 MAY send the accurate ECN feedback negotiation option in an initial 156 SYN segment and MAY send a more accurate ECN option (see Section 3) 157 in other segments only if it received this option negotiation in the 158 initial segment or for the connection. A TCP 159 receiver MAY send an segment with the accurate ECN feedback 160 negotiation option in response to a received accurate ECN feedback 161 negotiation option in the . If both ends indicate that they 162 support Accurate ECN (AccECN) feedback, the AccECN option SHOULD be 163 used in any subsequent TCP segment. A TCP sender or receiver MUST 164 only negotiate for the AccECN option if ECN is negotiated as well. 166 3. Accurate ECN (AccECN) feedback Option Specification 168 A TCP receiver, that provides Accurate ECN feedback, will maintain a 169 counter for the number of ECT(0), ECT(1), CE, non-ECT marked and lost 170 packets as well as the cumulative number of bytes of CE marked 171 packets. The TCP option to provide the Accurate ECN (AccECN) 172 feedback to the sender will echo these counters. 174 TCP Accurate ECN Option: 176 Kind: TBD (same as above) 178 Length: 12 bytes 180 +------+------+---------+---------+-------+-------+-------+-----------+ 181 | Kind | 12 | ECT(0) | ECT(1) | CE |non-ECT| loss |CE in bytes| 182 +------+------+---------+---------+-------+-------+-------+-----------+ 183 1 1 2 2 1 1 1 3 185 Figure 2: Accurate ECN feedback TCP option 187 TCP anyway provides a mechanism to detect loss as loss should always 188 be assumes as a strong signal for congestion and TCP congestion 189 control reacts on loss. If TCP SACK is not available, the exact 190 number of losses is not known. Moreover, the TCP loss detection 191 (incl. SACK) is done in bytes and not in number of packets. The 192 number of lost packets can be used by the sender to calculate the ECN 193 Nonce sum more exactly. 195 The same feedback information are proposed for the (ECN) feedback in 196 RTP (see [I-D.ietf-avtcore-ecn-for-rtp]. 198 As TCP is a bi-directional protocol, this option can be used in both 199 directions. With the reception of every data segment at least one of 200 the counters changes (ETC(0) or ETC(1)). The AccECN option SHOULD be 201 included in every ACK to ensure the reception of the ECN feedback at 202 the sender in case of ACK loss. To reduce network load the AccECN 203 option MAY not be send in every ACK, e.g. only in very second ACK (if 204 ACKs are sent very frequently). 206 In general it is possible that any of the counters wraps around. In 207 this case the information might get corrupted if e.g. for any reason 208 only one ACK per RTT is sent and more than 256 CE marks occur in one 209 RTT. For this case it MUST be ensured, that at least three ACKs/ 210 segments with the AccECN option have been sent prior to the counter 211 experiencing an wrap around. Whenever an AccECN Option is received 212 with smaller counter value than in the previous one and the 213 respective ACK acknowledges new data, a wrap around MUST be assumed. 215 4. Acknowledgements 217 5. IANA Considerations 219 TBD 221 6. Security Considerations 223 TBD 225 7. References 227 7.1. Normative References 229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, March 1997. 232 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 233 of Explicit Congestion Notification (ECN) to IP", 234 RFC 3168, September 2001. 236 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 237 Congestion Notification (ECN) Signaling with Nonces", 238 RFC 3540, June 2003. 240 7.2. Informative References 242 [Ali10] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, 243 P., Prabhakar, B., Sengupta, S., and M. Sridharan, "DCTCP: 244 Efficient Packet Transport for the Commoditized Data 245 Center", Jan 2010. 247 [I-D.briscoe-tsvwg-re-ecn-tcp] 248 Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith, 249 "Re-ECN: Adding Accountability for Causing Congestion to 250 TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-09 (work in 251 progress), October 2010. 253 [I-D.ietf-avtcore-ecn-for-rtp] 254 Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 255 and K. Carlberg, "Explicit Congestion Notification (ECN) 256 for RTP over UDP", draft-ietf-avtcore-ecn-for-rtp-08 (work 257 in progress), May 2012. 259 [I-D.kuehlewind-conex-accurate-ecn] 260 Kuehlewind, M. and R. Scheffenegger, "Accurate ECN 261 Feedback in TCP", draft-kuehlewind-conex-accurate-ecn-01 262 (work in progress), October 2011. 264 Authors' Addresses 266 Mirja Kuehlewind (editor) 267 University of Stuttgart 268 Pfaffenwaldring 47 269 Stuttgart 70569 270 Germany 272 Email: mirja.kuehlewind@ikr.uni-stuttgart.de 274 Richard Scheffenegger 275 NetApp, Inc. 276 Am Euro Platz 2 277 Vienna, 1120 278 Austria 280 Phone: +43 1 3676811 3146 281 Email: rs@netapp.com