idnits 2.17.1 draft-morton-taht-tsvwg-sce-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC8311, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3168, but the abstract doesn't seem to directly say this. It does mention RFC3168 though, so this could be OK. 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). (Using the creation date from RFC3168, updated by this document, for RFC5378 checks: 2000-11-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 10, 2019) is 1871 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3168' is mentioned on line 100, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Working Group J. Morton 3 Internet-Draft Bufferbloat.net 4 Updates: 3168, 8311 (if approved) D. Taeht 5 Intended status: Standards Track TekLibre 6 Expires: September 11, 2019 March 10, 2019 8 The Some Congestion Experienced ECN Codepoint 9 draft-morton-taht-tsvwg-sce-00 11 Abstract 13 This memo reclassifies ECT(1) to be an early notification of 14 congestion on ECT(0) marked packets, which can be used by AQM 15 algorithms and transports as an earlier signal of congestion than CE. 16 It is a simple, transparent, and backward compatible upgrade to 17 existing IETF-approved AQMs, RFC3168, and nearly all congestion 18 control algorithms. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 11, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 4. Some Congestion Experienced . . . . . . . . . . . . . . . . . 3 58 5. Examples of use . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Cubic . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5.2. TCP receiver side handling . . . . . . . . . . . . . . . 5 61 5.3. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 5 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 10.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Terminology 73 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 74 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 75 document, are to be interpreted as described in [RFC2119]. 77 2. Introduction 79 This memo reclassifies ECT(1) to be an early notification of 80 congestion on ECT(0) marked packets, which can be used by AQM 81 algorithms and transports as an earlier signal of congestion than CE 82 ("Congestion Experienced"). 84 This memo limits its scope to the redefinition of the ECT(1) 85 codepoint as SCE, "Some Congestion Experienced", with a few brief 86 illustrations of how it may be used. 88 3. Background 90 [RFC3168] defines the lower two bits of the (former) TOS byte in the 91 IPv4/6 header as the ECN field. This may take four values: Not-ECT, 92 ECT(0), ECT(1) or CE. 94 Binary Keyword References 96 ------------------------------------------------------------ 97 00 Not-ECT (Not ECN-Capable Transport) [RFC 3168] 98 01 ECT(1) (ECN-Capable Transport(1)) [RFC 3168] 99 10 ECT(0) (ECN-Capable Transport(0)) [RFC 3168] 100 11 CE (Congestion Experienced) [RFC 3168] 102 Research has shown that the ECT(1) codepoint goes essentially unused, 103 with the "Nonce Sum" extension to ECN having not been implemented in 104 practice and thus subsequently obsoleted by [RFC8311] (section 3). 105 Additionally, known [RFC3168] compliant senders do not emit ECT(1), 106 and compliant middleboxes do not alter the field to ECT(1), while 107 compliant receivers all interpret ECT(1) identically to ECT(0). 108 These are useful properties which represent an opportunity for 109 improvement. 111 Experience gained with 7 years of [RFC8290] deployment in the field 112 suggests that it remains difficult to maintain the desired 100% link 113 utilisation, whilst simultaneously strictly minimising induced delay 114 due to excess queue depth - irrespective of whether ECN is in use. 115 This leads to a reluctance amongst hardware vendors to implement the 116 most effective AQM schemes because their headline benchmarks are 117 throughput-based. 119 The underlying cause is the very sharp "multiplicative decrease" 120 reaction required of transport protocols to congestion signalling 121 (whether that be packet loss or CE marks), which tends to leave the 122 congestion window significantly smaller than the ideal BDP when 123 triggered at only slightly above the ideal value. The availability 124 of this sharp response is required to assure network stability (AIMD 125 principle), but there is presently no standardised and backwards- 126 compatible means of providing a less drastic signal. 128 4. Some Congestion Experienced 130 As consensus has arisen that some form of ECN signaling should be an 131 earlier signal than drop, this Internet Draft changes the meaning of 132 ECT(1) to be SCE, meaning "Some Congestion Experienced". The above 133 ECN-field codepoint table then becomes: 135 Binary Keyword References 137 ------------------------------------------------------------ 139 00 Not-ECT (Not ECN-Capable Transport) [@RFC3168] 140 01 SCE (Some Congestion Experienced) [This Internet-draft] 141 10 ECT (ECN-Capable Transport) [@RFC3168] 142 11 CE (Congestion Experienced) [@RFC3168] 144 This permits middleboxes implementing AQM to signal incipient 145 congestion, below the threshold required to justify setting CE, by 146 converting some proportion of ECT codepoints to SCE ("SCE marking"). 147 Existing [RFC3168] compliant receivers MUST transparently ignore this 148 new signal, and both existing and SCE-aware middleboxes MAY convert 149 SCE to CE in the same circumstances as for ECT, thus ensuring 150 backwards compatibility with [RFC3168] ECN endpoints. 152 Permitted ECN codepoint packet transitions by middleboxes are: 154 Not-ECT -> Not-ECT or DROP 155 ECT -> ECT or SCE or CE or DROP 156 SCE -> SCE or CE or DROP 157 CE -> CE or DROP 159 In other words, for ECN-aware flows, the ECN marking of an individual 160 packet MAY be increased by a middlebox to signal congestion, but MUST 161 NOT be decreased, and packets SHALL NOT be altered to appear to be 162 ECN-aware if they were not originally, nor vice versa. Note however 163 that SCE is numerically less than ECT, but semantically greater, and 164 the latter definition applies for this rule. 166 New SCE-aware receivers and transport protocols SHALL continue to 167 apply the [RFC3168] interpretation of the CE codepoint, that is, to 168 signal the sender to back off send rate to the same extent as if a 169 packet loss were detected. This maintains compatibility with 170 existing middleboxes, senders and receivers. 172 New SCE-aware receivers and transport protocols SHOULD interpret the 173 SCE codepoint as an indication of mild congestion, and respond 174 accordingly by applying send rates intermediate between those 175 resulting from a continuous sequence of ECT codepoints, and those 176 resulting from a CE codepoint. The ratio of ECT and SCE codepoints 177 received indicates the relative severity of such congestion, such 178 that 100% SCE is very close to the threshold of CE marking, 100% ECT 179 indicates that the bottleneck link may not be fully utilised, and a 180 1:1 balance of ECT and SCE codepoints indicates that the present send 181 rate is a good match to the bottleneck link. 183 Details of how to implement SCE awareness at the transport layer will 184 be left to additional Internet Drafts yet to be submitted. 186 To maximise the benefit of SCE, middleboxes SHOULD produce SCE 187 markings sooner than they produce CE markings, when the level of 188 congestion increases. 190 5. Examples of use 192 5.1. Cubic 194 Consider a TCP transport implementing CUBIC congestion control. This 195 presently exhibits exponential cwnd growth during slow-start, 196 polynomial cwnd growth in steady-state, and multiplicative decrease 197 upon detecting a single CE marking or packet loss in one RTT cycle. 199 With SCE awareness, it might exit slow-start upon detecting a single 200 SCE marking, switch from polynomial to Reno-linear cwnd growth when 201 the SCE:ECT ratio exceeds 1:2, halt cwnd growth entirely when it 202 exceeds 1:1, and implement a Reno-linear decline when it exceeds 2:1, 203 in addition to retaining the sharp 40% decrease on detecting CE. 205 In ideal circumstances, the above behaviour would result in the send 206 rate stabilising at a level which produces between 50% and 66% SCE 207 marking at some bottleneck on the path. The middlebox performing 208 this marking can thus control the send rate smoothly to an ideal 209 value, maximising throughput with minimum average queue length. 211 5.2. TCP receiver side handling 213 SCE can potentially be handled entirely by the receiver and be 214 entirely independent of any of the dozens of [RFC3168] compliant 215 congestion control algorithms, for example by manipulating the TCP 216 receive window in a similar manner to the sender's congestion window. 218 Alternatively, some mechanism may be defined to feed back SCE signals 219 to the sender explicitly. Details of this are left to future I-Ds. 221 5.3. Other 223 New transports under development such as QUIC SHOULD implement a 224 multi-bit, sub-RTT, and finer grained signal back to the sender based 225 on SCE. 227 6. Related Work 229 [RFC8087] [RFC7567] [RFC7928] [RFC8290] [RFC8289] [RFC8033] [RFC8034] 231 7. IANA Considerations 233 There are no IANA considerations. 235 8. Security Considerations 237 There are no security considerations. 239 9. Acknowledgements 241 Many thanks to John Gilmore, the members of the ecn-sane project and 242 the cake@lists.bufferbloat.net mailing list, and the former IETF AQM 243 working group. 245 10. References 247 10.1. Normative References 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, 251 DOI 10.17487/RFC2119, March 1997, 252 . 254 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 255 Notification (ECN) Experimentation", RFC 8311, 256 DOI 10.17487/RFC8311, January 2018, 257 . 259 10.2. Informative References 261 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 262 of Explicit Congestion Notification (ECN) to IP", 263 RFC 3168, DOI 10.17487/RFC3168, September 2001, 264 . 266 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 267 Recommendations Regarding Active Queue Management", 268 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 269 . 271 [RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N., Ed., and 272 D. Ros, "Characterization Guidelines for Active Queue 273 Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July 274 2016, . 276 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 277 "Proportional Integral Controller Enhanced (PIE): A 278 Lightweight Control Scheme to Address the Bufferbloat 279 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 280 . 282 [RFC8034] White, G. and R. Pan, "Active Queue Management (AQM) Based 283 on Proportional Integral Controller Enhanced PIE) for 284 Data-Over-Cable Service Interface Specifications (DOCSIS) 285 Cable Modems", RFC 8034, DOI 10.17487/RFC8034, February 286 2017, . 288 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 289 Explicit Congestion Notification (ECN)", RFC 8087, 290 DOI 10.17487/RFC8087, March 2017, 291 . 293 [RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. 294 Iyengar, Ed., "Controlled Delay Active Queue Management", 295 RFC 8289, DOI 10.17487/RFC8289, January 2018, 296 . 298 [RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, 299 J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler 300 and Active Queue Management Algorithm", RFC 8290, 301 DOI 10.17487/RFC8290, January 2018, 302 . 304 Authors' Addresses 306 Jonathan Morton 307 Bufferbloat.net 308 Koekkoenranta 21 309 PITKAeJAeRVI 31520 310 FINLAND 312 Phone: +358 44 927 2377 313 Email: chromatix99@gmail.com 315 David M. Taeht 316 TekLibre 317 20600 Aldercroft Heights Rd 318 Los Gatos, Ca 95033 319 USA 321 Phone: +18312059740 322 Email: dave@taht.net