idnits 2.17.1 draft-gomez-tcpm-ack-rate-request-02.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 (February 19, 2021) is 1154 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: August 23, 2021 University of Cambridge 6 February 19, 2021 8 TCP ACK Rate Request Option 9 draft-gomez-tcpm-ack-rate-request-02 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 August 23, 2021. 41 Copyright Notice 43 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . 7 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 8.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 format (with the appropriate Length 145 value, see Section 4) in packets that have the SYN bit set. 147 The next two subsections define the sender and receiver behaviors for 148 devices that support the TARR option, respectively. 150 3.1. Sender behavior 152 A TCP sender MUST NOT include the TARR option in TCP data segments to 153 be sent if the TCP receiver does not support the TARR option. 155 A TCP sender MAY request a TARR-option-capable receiver to modify the 156 ACK rate of the latter to one ACK every R full-sized data segments 157 received from the sender. This request is performed by the sender by 158 including the TARR option in the TCP header of a data segment. The 159 TARR option carries the R value requested by the sender (see section 160 4). For the described purpose, the value of R MUST NOT be zero. The 161 TARR option also carries the N field, which MUST be ignored when R is 162 not set to zero. 164 When a TCP sender needs a data segment to be acknowledged immediately 165 by a TARR-option-capable receiving TCP, the sender includes the TARR 166 option in the TCP header of the data segment, with a value of R equal 167 to zero. When R is set to zero, the N field of the same option 168 indicates the number of subsequent data segments for which the sender 169 also requests immediate ACKs. 171 A TCP sender MAY indicate that it has a reordering tolerance of R 172 packets by setting the Ignore Order field of the TARR option to True 173 (see Section 4). 175 3.2. Receiver behavior 177 A receiving TCP conforming to this specification MUST process a TARR 178 option present in a received data segment. 180 When the TARR option of a received segment carries an R value 181 different from zero, a TARR-option-capable receiving TCP MUST modify 182 its ACK rate to one ACK every R full-sized received data segments 183 from the sender, as long as packet reordering does not occur. When R 184 is different from zero, the receiving TCP MUST ignore the N field of 185 the TARR option. 187 A TARR-option-capable TCP that receives a TARR option with the Ignore 188 Order (I) field set to True (see Section 4), MUST NOT send an ACK 189 after each reordered data segment. Instead, it MUST continue to send 190 one ACK every R received data segments. Otherwise (i.e., Ignore 191 Order = False), such a receiver will need to send an ACK after each 192 reordered data segment received. 194 If a TARR-option-capable TCP receives a segment carrying the TARR 195 option with R=0, the receiving TCP MUST send an ACK immediately, and 196 it MUST also send an ACK immediately after each one of the N next 197 consecutive segments to be received. N refers to the corresponding 198 field in the TARR option of the received segment (see Section 4). 200 4. Option Format 202 The TARR option presents two different formats that can be identified 203 by the corresponding format length. For packets that have the SYN 204 bit set, the TARR option has the format shown in Fig. 1. 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Kind | Length | ExID | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 1: TCP ACK Rate Request option format for packets that have 213 the SYN bit set. 215 Kind: The Kind field value is TBD. 217 Length: The Length field value is 4 bytes. 219 ExID: The experiment ID field size is 2 bytes, and its value is 220 0x00AC. 222 For packets that do not have the SYN bit set, the TARR option has the 223 format and content shown in Fig. 2. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Kind | Length | ExID | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | R |I| N | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Figure 2: TCP ACK Rate Request option format. 235 Kind: The Kind field value is TBD. 237 Length: The Length field value is 6 bytes. 239 ExID: The experiment ID field size is 2 bytes, and its value is 240 0x00AC. 242 R: The size of this field is 7 bits. If all bits of this field are 243 set to 0, the field indicates a request by the sender for the 244 receiver to trigger one or more ACKs immediately. Otherwise, the 245 field carries the binary encoding of the number of full-sized 246 segments received after which the receiver is requested by the sender 247 to send an ACK. 249 Ignore Order (I): The size of this field is 1 bit. This field either 250 has the value 1 ("True") or 0 ("False"). When this field is set to 251 True, the receiver MUST NOT send an ACK after each reordered data 252 segment. Instead, it MUST continue to send one ACK every R received 253 data segments. 255 N: The size of this field is 1 byte. When R=0, the N field indicates 256 the number of subsequent consecutive data segments to be sent for 257 which immediate ACKs are requested by the sender. 259 5. IANA Considerations 261 This document specifies a new TCP option (TCP ACK Rate Request) that 262 uses the shared experimental options format [RFC6994], with ExID in 263 network-standard byte order. 265 The authors plan to request the allocation of ExID value 0x00AC for 266 the TCP option specified in this document. 268 6. Security Considerations 270 The TARR option opens the door to new security threats. This section 271 discusses such new threats, and suggests mitigation techniques. 273 An attacker might be able to impersonate a legitimate sender, and 274 forge an apparently valid packet intended for the receiver, in order 275 to intentionally communicate a bad R value to the latter with the aim 276 to damage communication or device performance. For example, in a 277 small cwnd scenario, using a too high R value may lead to exacerbated 278 RTT increase and throughput decrease. In other scenarios, a too low 279 R value may contribute to depleting the energy of a battery-operated 280 receiver at a faster rate or may lead to increased network packet 281 load. 283 While Transport Layer Security (TLS) [RFC8446] is strongly 284 recommended for securing TCP-based communication, TLS does not 285 protect TCP headers, and thus cannot protect the TARR option fields 286 carried by a segment. One approach to address the problem is using 287 network-layer protection, such as Internet Protocol Security (IPsec) 288 [RFC4301]. 290 7. Acknowledgments 292 Bob Briscoe, Jonathan Morton, Richard Scheffenegger, Neal Cardwell, 293 Michael Tuexen, Yuchung Cheng, Matt Mathis, Jana Iyengar, Gorry 294 Fairhurst, and Stuart Cheshire provided useful comments and input for 295 this document. Jana Iyengar suggested including a field to allow a 296 sender communicate its tolerance to reordering. Gorry Fairhurst 297 suggested adding a mechanism to request a number of consecutive 298 immediate ACKs. 300 Carles Gomez has been funded in part by the Spanish Government 301 through project PID2019-106808RA-I00, and by Secretaria 302 d'Universitats i Recerca del Departament d'Empresa i Coneixement de 303 la Generalitat de Catalunya 2017 through grant SGR 376. 305 8. References 307 8.1. Normative References 309 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 310 Communication Layers", STD 3, RFC 1122, 311 DOI 10.17487/RFC1122, October 1989, 312 . 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, 316 DOI 10.17487/RFC2119, March 1997, 317 . 319 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 320 RFC 6994, DOI 10.17487/RFC6994, August 2013, 321 . 323 8.2. Informative References 325 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 326 Sooriyabandara, "TCP Performance Implications of Network 327 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 328 December 2002, . 330 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 331 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 332 December 2005, . 334 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 335 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 336 . 338 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 339 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 340 RFC 8490, DOI 10.17487/RFC8490, March 2019, 341 . 343 Authors' Addresses 345 Carles Gomez 346 UPC 347 C/Esteve Terradas, 7 348 Castelldefels 08860 349 Spain 351 Email: carlesgo@entel.upc.edu 353 Jon Crowcroft 354 University of Cambridge 355 JJ Thomson Avenue 356 Cambridge, CB3 0FD 357 United Kingdom 359 Email: jon.crowcroft@cl.cam.ac.uk