idnits 2.17.1 draft-gomez-tcpm-ack-rate-request-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 31, 2020) is 1266 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. 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 Working Group C. Gomez 3 Internet-Draft UPC 4 Intended status: Experimental J. Crowcroft 5 Expires: May 4, 2021 University of Cambridge 6 October 31, 2020 8 TCP ACK Rate Request Option 9 draft-gomez-tcpm-ack-rate-request-01 11 Abstract 13 TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism 14 that allows reducing protocol overhead in many scenarios. However, 15 Delayed ACKs may also contribute to suboptimal performance. When a 16 relatively large congestion window (cwnd) can be used, less frequent 17 ACKs may be desirable. On the other hand, in relatively small cwnd 18 scenarios, eliciting an immediate ACK may avoid unnecessary delays 19 that may be incurred by the Delayed ACKs mechanism. This document 20 specifies the TCP ACK Rate Request (TARR) option. This option allows 21 a sender to indicate the ACK rate to be used by a receiver, and it 22 also allows to request immediate ACKs from a receiver. 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 https://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 May 4, 2021. 41 Copyright Notice 43 Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions used in this document . . . . . . . . . . . . . . 3 60 3. TCP ACK Rate Request Functionality . . . . . . . . . . . . . 4 61 3.1. Sender behavior . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Receiver behavior . . . . . . . . . . . . . . . . . . . . 4 63 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 8.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 Delayed Acknowledgments (ACKs) were specified for TCP with the aim to 75 reduce protocol overhead [RFC1122]. With Delayed ACKs, a TCP delays 76 sending an ACK by up to 500 ms (often 200 ms, with lower values in 77 recent implementations such as ~50 ms also reported), and typically 78 sends an ACK for at least every second segment received in a stream 79 of full-sized segments. This allows combining several segments into 80 a single one (e.g. the application layer response to an application 81 layer data message, and the corresponding ACK), and also saves up to 82 one of every two ACKs, under many traffic patterns (e.g. bulk 83 transfers). The "SHOULD" requirement level for implementing Delayed 84 ACKs in RFC 1122, along with its expected benefits, has led to a 85 widespread deployment of this mechanism. 87 However, there exist scenarios where Delayed ACKs contribute to 88 suboptimal performance. We next roughly classify such scenarios into 89 two main categories, in terms of the congestion window (cwnd) size 90 and the Maximum Segment Size (MSS) that would be used therein: i) 91 "large" cwnd scenarios (i.e. cwnd >> MSS), and ii) "small" cwnd 92 scenarios (e.g. cwnd up to ~MSS). 94 In "large" cwnd scenarios, increasing the number of data segments 95 after which a receiver transmits an ACK beyond the typical one (i.e. 96 2 when Delayed ACKs are used) may provide significant benefits. One 97 example is mitigating performance limitations due to asymmetric path 98 capacity (e.g. when the reverse path is significantly limited in 99 comparison to the forward path) [RFC3449]. Another advantage is 100 reducing the computational cost both at the sender and the receiver, 101 and reducing network packet load, due to the lower number of ACKs 102 involved. 104 In many "small" cwnd scenarios, a sender may want to request the 105 receiver to acknowledge a data segment immediately (i.e. without the 106 additional delay incurred by the Delayed ACKs mechanism). In high 107 bit rate environments (e.g. data centers), a flow's fare share of the 108 available Bandwidth Delay Product (BDP) may be in the order of one 109 MSS, or even less. For an accordingly set cwnd value (e.g. cwnd up 110 to MSS), Delayed ACKs would incur a delay that is several orders of 111 magnitude greater than the RTT, severely degrading performance. Note 112 that the Nagle algorithm may produce the same effect for some traffic 113 patterns in the same type of environments [RFC8490]. In addition, 114 when transactional data exchanges are performed over TCP, or when the 115 cwnd size has been reduced, eliciting an immediate ACK from the 116 receiver may avoid idle times and allow timely continuation of data 117 transmission and/or cwnd growth, contributing to maintaining low 118 latency. 120 Further "small" cwnd scenarios can be found in Internet of Things 121 (IoT) environments. Many IoT devices exhibit significant memory 122 constraints, such as only enough RAM for a send buffer size of 1 MSS. 123 In that case, if the data segment does not elicit an application- 124 layer response, the Delayed ACKs mechanism unnecessarily contributes 125 a delay equal to the Delayed ACK timer to ACK transmission. The 126 sender cannot transmit a new data segment until the ACK corresponding 127 to the previous data segment is received and processed. 129 With the aim to provide a tool for performance improvement in both 130 "large" and "small" cwnd scenarios, this document specifies the TCP 131 ACK Rate request (TARR) option. This option allows a sender to 132 indicate the ACK rate to be used by a receiver, and it also allows to 133 request immediate ACKs from a receiver. 135 2. Conventions used in this document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 3. TCP ACK Rate Request Functionality 143 A TCP endpoint announces that it supports the TARR option by 144 including the TARR option format in packets that have the SYN bit 145 set. In such packets, the values carried by the TARR option format 146 other than Kind, Length and ExID MUST be ignored by the receiving 147 TCP. 149 TBD1: perhaps two formats (with one codepoint each), a shorter one 150 just to advertise that TARR is supported, and a larger one which is 151 the current TARR option format defined in section 4? 153 The next two subsections define the sender and receiver behaviors for 154 devices that support the TARR option, respectively. 156 3.1. Sender behavior 158 A TCP sender MUST NOT include the TARR option in TCP data segments to 159 be sent if the TCP receiver does not support the TARR option. 161 A TCP sender MAY request a TARR-option-capable receiver to modify the 162 ACK rate of the latter to one ACK every R full-sized data segments 163 received from the sender. This request is performed by the sender by 164 including the TARR option in the TCP header of a data segment. The 165 TARR option carries the R value requested by the sender (see section 166 4). For the described purpose, the value of R MUST NOT be zero. The 167 TARR option also carries the N field, which MUST be ignored when R is 168 not set to zero. 170 When a TCP sender needs a data segment to be acknowledged immediately 171 by a TARR-option-capable receiving TCP, the sender includes the TARR 172 option in the TCP header of the data segment, with a value of R equal 173 to zero. When R is set to zero, the N field of the same option 174 indicates the number of subsequent data segments for which the sender 175 also requests immediate ACKs. 177 A TCP sender MAY indicate that it has a reordering tolerance of R 178 packets by setting the Ignore Order field of the TARR option to True 179 (see Section 4). 181 3.2. Receiver behavior 183 A receiving TCP conforming to this specification MUST process a TARR 184 option present in a received data segment. 186 When the TARR option of a received segment carries an R value 187 different from zero, a TARR-option-capable receiving TCP MUST modify 188 its ACK rate to one ACK every R full-sized received data segments 189 from the sender, as long as packet reordering does not occur. When R 190 is different from zero, the receiving TCP MUST ignore the N field of 191 the TARR option. 193 A TARR-option-capable TCP that receives a TARR option with the Ignore 194 Order field set to True (see Section 4), MUST NOT send an ACK after 195 each reordered data segment. Instead, it MUST continue to send one 196 ACK every R received data segments. Otherwise (i.e., Ignore Order = 197 False), such a receiver will need to send an ACK after each reordered 198 data segment received. 200 If a TARR-option-capable TCP receives a segment carrying the TARR 201 option with R=0, the receiving TCP MUST send an ACK immediately, and 202 it MUST also send an ACK immediately after each one of the N next 203 consecutive segments to be received. N refers to the corresponding 204 field in the TARR option of the received segment (see Section 4). 206 4. Option Format 208 The TARR option has the format and content shown in Fig. 1. 210 0 1 2 3 211 01234567 89012345 67890123 45678901 212 +--------+--------+--------+--------+ 213 | Kind | Length | ExID | 214 +--------+--------+--------+--------+ 215 | R | IgnOrd | N | 216 +--------+--------+--------+ 218 Figure 1: TCP ACK Rate Request option format. 220 Kind: The Kind field value is TBD. 222 Length: The Length field value is 7 bytes. 224 ExID: The experiment ID field size is 2 bytes, and its value is 225 0x00AC. 227 R: The size of this field is 1 byte. If all bits of this field are 228 set to 0, the field indicates a request by the sender for the 229 receiver to trigger one or more ACKs immediately. Otherwise, the 230 field carries the binary encoding of the number of full-sized 231 segments received after which the receiver is requested by the sender 232 to send an ACK. 234 Ignore Order: The size of this field is 1 byte. This field MUST have 235 the value 0x01 ("True") or 0x00 ("False"). When this field is set to 236 True, the receiver MUST NOT send an ACK after each reordered data 237 segment. Instead, it MUST continue to send one ACK every R received 238 data segments. 240 TBD2: perhaps 7 bits for R and 1 bit for Ignore Order? 242 N: The size of this field is 1 byte. When R=0, the N field indicates 243 the number of subsequent consecutive data segments to be sent for 244 which immediate ACKs are requested by the sender. 246 5. IANA Considerations 248 This document specifies a new TCP option (TCP ACK Rate Request) that 249 uses the shared experimental options format [RFC6994], with ExID in 250 network-standard byte order. 252 The authors plan to request the allocation of ExID value 0x00AC for 253 the TCP option specified in this document. 255 6. Security Considerations 257 TBD 259 7. Acknowledgments 261 Bob Briscoe, Jonathan Morton, Richard Scheffenegger, Neal Cardwell, 262 Michael Tuexen, Yuchung Cheng, Matt Mathis, Jana Iyengar, Gorry 263 Fairhurst, and Stuart Cheshire provided useful comments and input for 264 this document. Jana Iyengar suggested including a field to allow a 265 sender communicate its tolerance to reordering. Gorry Fairhurst 266 suggested adding a mechanism to request a number of consecutive 267 immediate ACKs. 269 Carles Gomez has been funded in part by the Spanish Government 270 through project PID2019-106808RA-I00, and by Secretaria 271 d'Universitats i Recerca del Departament d'Empresa i Coneixement de 272 la Generalitat de Catalunya 2017 through grant SGR 376. 274 8. References 276 8.1. Normative References 278 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 279 Communication Layers", STD 3, RFC 1122, 280 DOI 10.17487/RFC1122, October 1989, 281 . 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, 285 DOI 10.17487/RFC2119, March 1997, 286 . 288 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 289 RFC 6994, DOI 10.17487/RFC6994, August 2013, 290 . 292 8.2. Informative References 294 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 295 Sooriyabandara, "TCP Performance Implications of Network 296 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 297 December 2002, . 299 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 300 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 301 RFC 8490, DOI 10.17487/RFC8490, March 2019, 302 . 304 Authors' Addresses 306 Carles Gomez 307 UPC 308 C/Esteve Terradas, 7 309 Castelldefels 08860 310 Spain 312 Email: carlesgo@entel.upc.edu 314 Jon Crowcroft 315 University of Cambridge 316 JJ Thomson Avenue 317 Cambridge, CB3 0FD 318 United Kingdom 320 Email: jon.crowcroft@cl.cam.ac.uk