idnits 2.17.1 draft-grimes-tcpmwg-tcpsce-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 : ---------------------------------------------------------------------------- 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 (8 July 2019) is 1753 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) == Outdated reference: A later version (-04) exists of draft-morton-tsvwg-sce-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.morton-tsvwg-sce' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions R.W. Grimes 3 Internet-Draft P. Heist 4 Intended status: Standards Track 8 July 2019 5 Expires: 9 January 2020 7 Some Congestion Experienced in TCP 8 draft-grimes-tcpmwg-tcpsce-00 10 Abstract 12 This memo classifies a TCP code point ESCE ("Echo Some Congestion 13 Experienced") for use in feedback of IP code point SCE ("Some 14 Congestion Experienced"). 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 https://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 9 January 2020. 33 Copyright Notice 35 Copyright (c) 2019 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 (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. TCP Receiver . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4.1. Single ACK implementation . . . . . . . . . . . . . . . . 3 54 4.2. Simple Delayed ACK implementation . . . . . . . . . . . . 3 55 4.3. Dithered Delayed ACK implementation . . . . . . . . . . . 3 56 5. TCP Sender . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 4 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 61 10. Normative References . . . . . . . . . . . . . . . . . . . . 4 62 11. Informative References . . . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Terminology 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 69 "OPTIONAL" in this document are to be interpreted as described in 70 [RFC2119] and [RFC8174] when, and only when, they appear in all 71 capitals, as shown here. 73 2. Introduction 75 This memo reclassifies the former TCP NS ("Nonce Sum") codepoint as 76 ESCE. 78 This memo limits its scope to the redefinition of the TCP NS 79 codepoint as ESCE, with a few brief illustrations of how it may be 80 used. 82 SCE provides early and proportional feedback to the CC (congestion 83 control) algorithms for transport protocols, including but not 84 limited to TCP. The [sce-repo] is a Linux kernel modified to support 85 SCE, including: 87 * Enhancements to Linux's Cake (Common Applications Kept Enhanced) 88 AQM to support SCE signaling 90 * Modifications to the TCP receive path to reflect SCE signals back 91 to the sender 93 * The addition of three new TCP CC algorithms that modify the 94 originals to add SCE support: Reno-SCE, DCTCP-SCE and Cubic-SCE 95 (work in progress as of this writing) 97 3. Background 99 [I-D.morton-tsvwg-sce] defines the SCE codepoint and [RFC8311] 100 (section 3) obsoletes the NS codepoint making it avaliable valiable 101 for use. 103 4. TCP Receiver 105 The mechanism defined to feed back SCE signals to the sender 106 explicitly makes use of the ESCE ("Echo Some Congestion Experienced") 107 code point in the TCP header. 109 4.1. Single ACK implementation 111 Upon receipt of a packet an ACK is immediatly generated, the SCE 112 codepoint is copied into the ESCE codepoint of the ACK. This keeps 113 the count of bytes SCE marked or not marked properly reflected in the 114 ACK packet(s). This valid implementation has the downside of 115 increasing ACK traffic. This implementation is NOT RECOMMENDED, but 116 useful for experimental work. 118 4.2. Simple Delayed ACK implementation 120 Upon receipt of a packet without an SCE codepoint traditional delayed 121 ACK processing is performed. Upon receipt of a packet with an SCE 122 codepoint immediate ACK processing SHOULD be done, this allows some 123 delaying of ACK's, but creates earlier feedback of the congested 124 state. This has the negative effect of over signalling ESCE. 126 4.3. Dithered Delayed ACK implementation 128 Upon receipt of a packet the SCE codepoint is stored in the TCP 129 state. Multiple packets state may be stored. Upon generation of an 130 ACK, normal or delayed, the stored SCE state is used to set the state 131 of ESCE. If no SCE state is in the TCP state, then the ESCE code 132 point MUST NOT be set. If all of the packets to be ACKed have SCE 133 state set then the ESCE code point MUST be set in the ACK. If some 134 of the packets to be ACKed have SCE state set then some proportional 135 number of ACK packets SHOULD be sent with the ESCE code point set. 136 The goal is to have the same number of bytes marked with ESCE as 137 arrived with SCE. 139 5. TCP Sender 141 The recommended response to each single segment marked with ESCE is 142 to reduce cwnd by an amortised 1/sqrt(cwnd) segments. Other 143 responses, such as the 1/cwnd from DCTCP, are also acceptable but may 144 perform less well. 146 This is still an area of continued investigation. 148 6. Related Work 150 TBD 152 7. IANA Considerations 154 There are no IANA considerations. 156 8. Security Considerations 158 There are no Security considerations. 160 9. Acknowledgements 162 TBD 164 10. Normative References 166 [I-D.morton-tsvwg-sce] 167 Morton, J. and R. Grimes, "The Some Congestion Experienced 168 ECN Codepoint", draft-morton-tsvwg-sce-00 (work in 169 progress), 2 July 2019, 170 . 173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14, RFC 2119, 175 DOI 10.17487/RFC2119, March 1997, 176 . 178 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 179 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 180 May 2017, . 182 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 183 Notification (ECN) Experimentation", RFC 8311, 184 DOI 10.17487/RFC8311, January 2018, 185 . 187 11. Informative References 189 [sce-repo] "Some Congestion Experienced Reference Implementation 190 GitHub Repository", July 2019, 191 . 193 Authors' Addresses 195 Rodney W. Grimes 196 Redacted 197 Portland, OR 97217 198 United States 200 Email: rgrimes@freebsd.org 202 Peter G. Heist 203 Redacted 204 463 11 Liberec 30 205 Czech Republic 207 Email: pete@heistp.net