idnits 2.17.1 draft-gomez-tcpm-ack-rate-request-04.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 (March 2022) is 774 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-tcpm-generalized-ecn-09 Summary: 0 errors (**), 0 flaws (~~), 3 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: 28 September 2022 University of Cambridge 6 March 2022 8 TCP ACK Rate Request Option 9 draft-gomez-tcpm-ack-rate-request-04 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 request 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 2 September 2022. 41 Copyright Notice 43 Copyright (c) 2022 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 (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 3. TCP ACK Rate Request Functionality . . . . . . . . . . . . . 4 60 3.1. Sender behavior . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Receiver behavior . . . . . . . . . . . . . . . . . . . . 4 62 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Changing the ACK rate during the lifetime of a TCP 64 connection . . . . . . . . . . . . . . . . . . . . . . . 6 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 9.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Delayed Acknowledgments (ACKs) were specified for TCP with the aim to 76 reduce protocol overhead [RFC1122]. With Delayed ACKs, a TCP delays 77 sending an ACK by up to 500 ms (often 200 ms, with lower values in 78 recent implementations such as ~50 ms also reported), and typically 79 sends an ACK for at least every second segment received in a stream 80 of full-sized segments. This allows combining several segments into 81 a single one (e.g. the application layer response to an application 82 layer data message, and the corresponding ACK), and also saves up to 83 one of every two ACKs, under many traffic patterns (e.g. bulk 84 transfers). The "SHOULD" requirement level for implementing Delayed 85 ACKs in RFC 1122, along with its expected benefits, has led to a 86 widespread deployment of this mechanism. 88 However, there exist scenarios where Delayed ACKs contribute to 89 suboptimal performance. We next roughly classify such scenarios into 90 two main categories, in terms of the congestion window (cwnd) size 91 and the Maximum Segment Size (MSS) that would be used therein: i) 92 "large" cwnd scenarios (i.e. cwnd >> MSS), and ii) "small" cwnd 93 scenarios (e.g. cwnd up to ~MSS). 95 In "large" cwnd scenarios, increasing the number of data segments 96 after which a receiver transmits an ACK beyond the typical one (i.e. 97 2 when Delayed ACKs are used) may provide significant benefits. One 98 example is mitigating performance limitations due to asymmetric path 99 capacity (e.g. when the reverse path is significantly limited in 100 comparison to the forward path) [RFC3449]. Another advantage is 101 reducing the computational cost both at the sender and the receiver, 102 and reducing network packet load, due to the lower number of ACKs 103 involved. 105 In many "small" cwnd scenarios, a sender may want to request the 106 receiver to acknowledge a data segment immediately (i.e. without the 107 additional delay incurred by the Delayed ACKs mechanism). In high 108 bit rate environments (e.g. data centers), a flow's fare share of the 109 available Bandwidth Delay Product (BDP) may be in the order of one 110 MSS, or even less. For an accordingly set cwnd value (e.g. cwnd up 111 to MSS), Delayed ACKs would incur a delay that is several orders of 112 magnitude greater than the RTT, severely degrading performance. Note 113 that the Nagle algorithm may produce the same effect for some traffic 114 patterns in the same type of environments [RFC8490]. In addition, 115 when transactional data exchanges are performed over TCP, or when the 116 cwnd size has been reduced, eliciting an immediate ACK from the 117 receiver may avoid idle times and allow timely continuation of data 118 transmission and/or cwnd growth, contributing to maintaining low 119 latency. 121 Further "small" cwnd scenarios can be found in Internet of Things 122 (IoT) environments. Many IoT devices exhibit significant memory 123 constraints, such as only enough RAM for a send buffer size of 1 MSS. 124 In that case, if the data segment does not elicit an application- 125 layer response, the Delayed ACKs mechanism unnecessarily contributes 126 a delay equal to the Delayed ACK timer to ACK transmission. The 127 sender cannot transmit a new data segment until the ACK corresponding 128 to the previous data segment is received and processed. 130 With the aim to provide a tool for performance improvement in both 131 "large" and "small" cwnd scenarios, this document specifies the TCP 132 ACK Rate request (TARR) option. This option allows a sender to 133 request the ACK rate to be used by a receiver, and it also allows to 134 request immediate ACKs from a receiver. 136 2. Conventions used in this document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 3. TCP ACK Rate Request Functionality 144 A TCP endpoint announces that it supports the TARR option by 145 including the TARR option format (with the appropriate Length value, 146 see Section 4) in packets that have the SYN bit set. 148 Upon reception of a SYN segment carrying the TARR option, a TARR- 149 option-capable endpoint MUST include the TARR option in the SYN-ACK 150 segment sent in response. 152 The next two subsections define the sender and receiver behaviors for 153 devices that support the TARR option, respectively. 155 3.1. Sender behavior 157 A TCP sender MUST NOT include the TARR option in TCP segments to be 158 sent if the TCP receiver does not support the TARR option. 160 A TCP sender MAY request a TARR-option-capable receiver to modify the 161 ACK rate of the latter to one ACK every R data segments received from 162 the sender. This request is performed by the sender by including the 163 TARR option in the TCP header of a segment. The TARR option carries 164 the R value requested by the sender (see section 4). 166 When a TCP sender needs a data segment to be acknowledged immediately 167 by a TARR-option-capable receiving TCP, the sender includes the TARR 168 option in the TCP header of the data segment, with a value of R equal 169 to 1. 171 A TCP segment carrying retransmitted data is not required to include 172 a TARR option. 174 3.2. Receiver behavior 176 A receiving TCP conforming to this specification MUST process a TARR 177 option present in a received segment. 179 A TARR-option-capable receiving TCP SHOULD modify its ACK rate to one 180 ACK every R received data segments from the sender. If a TARR- 181 option-capable TCP receives a segment carrying the TARR option with 182 R=1, the receiving TCP SHOULD send an ACK immediately. 184 If packet reordering occurs, a TARR-option-capable receiver should 185 send a duplicate ACK immediately when an out-of-order segment arrives 186 [RFC5681]. After sending a duplicate ACK, the receiver MAY send the 187 next non-duplicate ACK after R data segments received. Note also 188 that the receiver might be unable to send ACKs at the requested rate 189 (e.g., due to lack of resources); on the other hand, the receiver 190 might opt not to fulfill a request for security reasons (e.g., to 191 avoid or mitigate an attack by which a large number of senders 192 request disabling delayed ACKs simultaneously and send a large number 193 of data segments to the receiver). 195 The request to modify the ACK rate of the receiver holds until the 196 next segment carrying a TARR option is received. 198 4. Option Format 200 The TARR option presents two different formats that can be identified 201 by the corresponding format length. For packets that have the SYN 202 bit set, the TARR option has the format shown in Fig. 1. 204 0 1 2 3 205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Kind | Length | ExID | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 1: TCP ACK Rate Request option format for packets that 211 have the SYN bit set. 213 Kind: The Kind field value is TBD. 215 Length: The Length field value is 4 bytes. 217 ExID: The experiment ID field size is 2 bytes, and its value is 218 0x00AC. 220 For packets that do not have the SYN bit set, the TARR option has the 221 format and content shown in Fig. 2. 223 0 1 2 3 224 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Kind | Length | ExID | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | R |V| 229 +-+-+-+-+-+-+-+-+ 231 Figure 2: TCP ACK Rate Request option format. 233 Kind: The Kind field value is TBD. 235 Length: The Length field value is 5 bytes. 237 ExID: The experiment ID field size is 2 bytes, and its value is 238 0x00AC. 240 R: The size of this field is 7 bits. The field carries the ACK rate 241 requested by the sender. The minimum value of R is 1. 243 Note: there are currently two options being considered regarding the 244 semantics of the R field: 246 OPTION 1: the R field corresponds to the binary encoding of the 247 requested ACK rate. The maximum value of R is 127. A receiver MUST 248 ignore an R field with all bits set to zero. (TO-DO: if OPTION 1 is 249 selected, see how to handle all bits of R being equal to zero.) 251 OPTION 2: the R field is composed of two subfields: the 5 leftmost 252 bits represent a mantissa (m) and the 2 rightmost bits represent an 253 exponent (e). The value of the requested ACK rate is obtained as R = 254 (m+1)*2^(2*e). The maximum value of R is 2048. 256 ReserVed (V): The size of this field is 1 bit. This bit is reserved 257 for future use. 259 5. Changing the ACK rate during the lifetime of a TCP connection 261 In some scenarios, setting the ACK rate once for the whole lifetime 262 of a TCP connection may be suitable. However, there are also cases 263 where it may be desirable to modify the ACK rate during the lifetime 264 of a connection. 266 The ACK rate to be used may depend on the cwnd value used by the 267 sender, which can change over the lifetime of a connection. cwnd will 268 start at a low value and grow rapidly during the slow-start phase, 269 then settle into a reasonably consistent range for the congestion- 270 avoidance phase - assuming the underlying bandwidth-delay product 271 (BDP) remains constant. Phenomena such as routing updates, link 272 capacity changes or path load changes may modify the underlying BDP 273 significantly; the cwnd should be expected to change accordingly, 274 prompting the need for ACK rate updates. 276 TARR can also be used to suppress Delayed ACKs in order to allow 277 measuring the RTT of each packet in specific intervals (e.g., during 278 flow start-up), and allow a different ACK rate afterwards. 280 A Linux receiver has a heuristic to detect slow start and suppress 281 Delayed ACKs just for that period. However, some slow start variants 282 (e.g., HyStart, HyStart++, etc.) may alter the ending of slow start, 283 thus confusing the heuristics of the receiver. To avoid slow start 284 sender behavior ossification, an explicit signal such as TARR may be 285 useful. 287 Another reason to modify the ACK rate might be reducing the ACK load. 288 The sender may notice that the ACKs it receives cover more segments 289 than the ACK rate requested, indicating that ACK decimation is 290 occurring en route. The sender may then decide to reduce the ACK 291 frequency to reduce receiver workload and network load up to the ACK 292 decimation point. 294 Future TCP specifications may also permit Congestion Experienced (CE) 295 marks to appear on pure ACKs [I-D.ietf-tcpm-generalized-ecn]. This 296 might involve more frequent ACK rate updates (e.g., once an RTT), as 297 the sender probes around an operating point. 299 6. IANA Considerations 301 This document specifies a new TCP option (TCP ACK Rate Request) that 302 uses the shared experimental options format [RFC6994], with ExID in 303 network-standard byte order. 305 The authors plan to request the allocation of ExID value 0x00AC for 306 the TCP option specified in this document. 308 7. Security Considerations 310 The TARR option opens the door to new security threats. This section 311 discusses such new threats, and suggests mitigation techniques. 313 An attacker might be able to impersonate a legitimate sender, and 314 forge an apparently valid packet intended for the receiver. In such 315 case, the attacker may mount a variety of harmful actions. By using 316 TARR, the attacker may intentionally communicate a bad R value to the 317 latter with the aim to damage communication or device performance. 318 For example, in a small cwnd scenario, using a too high R value may 319 lead to exacerbated RTT increase and throughput decrease. In other 320 scenarios, a too low R value may contribute to depleting the energy 321 of a battery-operated receiver at a faster rate or may lead to 322 increased network packet load. 324 While Transport Layer Security (TLS) [RFC8446] is strongly 325 recommended for securing TCP-based communication, TLS does not 326 protect TCP headers, and thus cannot protect the TARR option fields 327 carried by a segment. One approach to address the problem is using 328 network-layer protection, such as Internet Protocol Security (IPsec) 329 [RFC4301]. Another solution is using the TCP Authentication Option 330 (TCP-AO), which provides TCP segment integrity and protection against 331 replay attacks [RFC5925]. 333 While it is relatively hard for an off-path attacker to attack an 334 unprotected TCP session, it is RECOMMENDED for a TARR receiver to use 335 the guidance and attack mitigation given in [RFC5961]. The TARR 336 option MUST be ignored on a packet that is deemed invalid. 338 A TARR receiver might opt not to fulfill a request to avoid or 339 mitigate an attack by which a large number of senders request 340 disabling delayed ACKs simultaneously and send a large number of data 341 segments to the receiver (see Section 3.2). 343 8. Acknowledgments 345 Bob Briscoe, Jonathan Morton, Richard Scheffenegger, Neal Cardwell, 346 Michael Tuexen, Yuchung Cheng, Matt Mathis, Jana Iyengar, Gorry 347 Fairhurst, Stuart Cheshire, Yoshifumi Nishida, Michael Scharf, Ian 348 Swett, and Martin Duke provided useful comments and input for this 349 document. Jana Iyengar suggested including a field to allow a sender 350 communicate its tolerance to reordering. Jonathan Morton and Bob 351 Briscoe provided the main input for Section 5. 353 Carles Gomez has been funded in part by the Spanish Government 354 through project PID2019-106808RA-I00, and by Secretaria 355 d'Universitats i Recerca del Departament d'Empresa i Coneixement de 356 la Generalitat de Catalunya 2017 through grant SGR 376. 358 9. References 360 9.1. Normative References 362 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 363 Communication Layers", STD 3, RFC 1122, 364 DOI 10.17487/RFC1122, October 1989, 365 . 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, 369 DOI 10.17487/RFC2119, March 1997, 370 . 372 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 373 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 374 . 376 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 377 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 378 June 2010, . 380 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 381 Robustness to Blind In-Window Attacks", RFC 5961, 382 DOI 10.17487/RFC5961, August 2010, 383 . 385 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 386 RFC 6994, DOI 10.17487/RFC6994, August 2013, 387 . 389 9.2. Informative References 391 [I-D.ietf-tcpm-generalized-ecn] 392 Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit 393 Congestion Notification (ECN) to TCP Control Packets", 394 Work in Progress, Internet-Draft, draft-ietf-tcpm- 395 generalized-ecn-09, 31 January 2022, 396 . 399 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 400 Sooriyabandara, "TCP Performance Implications of Network 401 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 402 December 2002, . 404 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 405 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 406 December 2005, . 408 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 409 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 410 . 412 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 413 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 414 RFC 8490, DOI 10.17487/RFC8490, March 2019, 415 . 417 Authors' Addresses 419 Carles Gomez 420 UPC 421 C/Esteve Terradas, 7 422 08860 Castelldefels 423 Spain 424 Email: carlesgo@entel.upc.edu 426 Jon Crowcroft 427 University of Cambridge 428 JJ Thomson Avenue 429 Cambridge 430 United Kingdom 431 Email: jon.crowcroft@cl.cam.ac.uk