idnits 2.17.1 draft-kuhn-quic-bdpframe-extension-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 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). -- The document date (6 March 2022) is 781 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-cardwell-iccrg-bbr-congestion-control-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. Kuhn 3 Internet-Draft 4 Intended status: Informational E. Stephan 5 Expires: 7 September 2022 Orange 6 G. Fairhurst 7 T. Jones 8 University of Aberdeen 9 C. Huitema 10 Private Octopus Inc. 11 6 March 2022 13 BDP Frame Extension 14 draft-kuhn-quic-bdpframe-extension-00 16 Abstract 18 This draft describes the BDP Frame extension for QUIC. It enables 19 the exchange of information related to the path characteristics 20 between the client and the server during a connection. This 21 information can later be exploited when a new connection is 22 established. 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 7 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 1.1. Notations and terms . . . . . . . . . . . . . . . . . . . 2 59 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2. BDP Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. BDP Frame Format . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Extension activation . . . . . . . . . . . . . . . . . . 5 63 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 7.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 This document proposes a method to exchange values between a client 75 and the server in a interoperable manner: 77 1. For an established connection, the current RTT (current_rtt), 78 bottleneck bandwidth (current_bb) and current client IP 79 (current_client_ip) are stored as saved_rtt, saved_bb and 80 saved_client_ip within a BDP_FRAME; 82 2. The BDP_FRAME can be sent to the client and the client can also 83 be notified of the values of the BDP_FRAME parameters; 85 3. When resuming a session to the same IP address, the client is 86 allowed to send the BDP_FRAME; 88 4. The server can then utilise the parameters from the BDP_FRAME in 89 a later new connection to the same endpoint. 91 This method applies to any resumed QUIC session: both a saved_session 92 and a recon_session can be a 0-RTT QUIC connection or a 1-RTT QUIC 93 connection. 95 1.1. Notations and terms 96 * BDP: defined below 98 * CWND: the congestion window used by server (maximum number of 99 bytes allowed in flight by the CC) 101 * current_bb : Current estimated bottleneck bandwidth 103 * saved_bb: Estimated bottleneck bandwidth preserved from a previous 104 connection 106 * RTT: Round-Trip Time 108 * current_rtt: Current RTT 110 * saved_rtt: RTT preserved from a previous connection 112 * client_ip : IP address of the client 114 * current_client_ip : Current IP address of the client 116 * saved_client_ip : IP address of the client preserved from a 117 previous connection 119 * remembered BDP parameters: a combination of saved_rtt and saved_bb 121 [RFC6349] defines the BDP as follows: "Derived from Round-Trip Time 122 (RTT) and network Bottleneck Bandwidth (BB), the Bandwidth-Delay 123 Product (BDP) determines the Send and Received Socket buffer sizes 124 required to achieve the maximum TCP Throughput." This document 125 considers the BDP estimated by a server that includes all buffering 126 along the network path. The estimated BDP estimated is related to 127 the amount of bytes in flight and the measured path RTT. 129 A QUIC connection could use the procedure detailed in [RFC6349] to 130 measure the BDP, but is permitted to choose another method [RFC9002] 131 . A server might be able to utilise an other information to provide 132 an estimate of the BDP. 134 Congestion controllers, such as CUBIC or RENO, could estimate the 135 saved_bb and current_bb values by utilizing a combination of the 136 cwnd/flight_size and the minimum RTT. A different method could be 137 used to estimate the same values when using a rate-based congestion 138 controller, such as BBR [I-D.cardwell-iccrg-bbr-congestion-control]. 139 It is important to consider whether the methods could result in over- 140 estimating the bottleneck bandwidth, and the preserved values there 141 ought to be used with caution. 143 1.2. Requirements Language 145 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 2. BDP Frame 153 This section describes the use of a new Frame, the BDP Frame. The 154 BDP Frame MUST be considered by the congestion controller and its 155 data is not be limited by flow control limits. The server and the 156 client MAY send multiple BDP Frames in both 1-RTT and 0-RTT 157 connections. 159 2.1. BDP Frame Format 161 A BDP Frame is formatted as shown in Figure 1. 163 BDP Frame { 164 Type (i) = 0xXXX, 165 Lifetime (i), 166 Saved BB (i), 167 Saved RTT (i), 168 Saved IP length (i), 169 Saved IP (...) 170 } 172 Figure 1: BDP Frame Format 174 A BDP Frame contains the following fields: 176 * Lifetime (extension_lifetime): The extension_lifetime is a value 177 in milliseconds, encoded as a variable length integer. This 178 follows the design of a NewSessionTicket of TLS [RFC8446]. This 179 represents the validity in time of this extension. 181 * Saved BB (saved_bb): The saved_bb is a value in bytes, encoded as 182 a variable length integer. The bottleneck bandwidth estimated for 183 the previous connection by the server. Using the previous values 184 of bytes_in_flight defined in [RFC9002] can result in overshoot of 185 the bottleneck capacity and is not advised. 187 * Saved RTT (saved_rtt): The saved_rtt is a value in milliseconds, 188 encoded as a variable length integer. This could be set to the 189 minimum RTT (min_rtt). The saved_rtt can be set to the min_rtt. 190 NOTE: The min_rtt defined in [RFC9002], does not track a 191 decreasing RTT: therefore the min_rtt reported might be larger 192 than the actual minimum RTT measured during the 1-RTT connection. 194 * Saved IP length (saved_ip_length) : The length of the IP address 195 in octets is set to either 4 (IPv4) or 16 (IPv6). 197 * Saved IP (saved_client_ip) : The saved_client_ip could be set to 198 the IP address of the client. 200 2.2. Extension activation 202 The client can accept the transmission of BDP Frames from the server 203 by using the enable_bdp transport extension. 205 enable_bdp (0xTBD): in the 1-RTT connection, the client indicates to 206 the server that it wishes to receive BDP extension Frames for 207 improving ingress of 0-RTT connection. The default value is 0. 208 Values larger than 3 are invalid, and receipt of these values MUST be 209 treated as a connection error of type TRANSPORT_PARAMETER_ERROR. 211 * 0: Default value. If the client does not send this parameter, the 212 server considers that the client does not support or does not wish 213 to activate the BDP extension. 215 * 1: The client indicates to the server that it wishes to receive 216 BDP Frame and activates the ingress optimization for the 0-RTT 217 connection. 219 * 2: The client indicates that it does not wish to receive BDP 220 Frames but activates ingress optimization. 222 * 3: The client indicates that it wishes to receive BDP Frames, but 223 does not activate ingress optimization. 225 This Transport Parameter is encoded as described in Section 18 of 226 [RFC9000]. 228 3. Discussion 230 With the BDP Frame extension, the client has the choice of accepting 231 the reuse of the previous parameters or not. 233 The BDP metadata parameters are measured by the server during a 234 previous connection. The BDP extension is protected by the mechanism 235 that protects the exchange of the 0-RTT transport parameters. For 236 version 1 of QUIC, the BDP extension is protected using the mechanism 237 that already protects the "initial_max_data" parameter. This is 238 defined in sections 4.5 to 4.7 of [RFC9001]. This provides a way for 239 the server to verify that the parameters proposed by the client are 240 the same as those that the server sent to the client during the 241 previous connection. 243 The server SHOULD NOT trust the client. Indeed, even if 0-RTT 244 packets containing the BDP Frame are encrypted, a client could modify 245 the values within the extension and encrypt the 0-RTT packet. 246 Authentication mechanisms might not guarantee that the values are 247 safe. It is not an easy operation for a client to modify 248 authenticated or encrypted data without this being detected by a 249 server. Modification could be realized by malicious clients. One 250 way to avoid this is for a server to also store the saved_rtt and 251 saved_bb parameters. 253 4. Acknowledgments 255 The authors would like to thank Gabriel Montenegro, Patrick McManus, 256 Ian Swett, Igor Lubashev, Robin Marx, Roland Bless and Franklin Simo 257 for their fruitful comments on earlier versions of this document. 259 5. IANA Considerations 261 TBD: Text is required to register the BDP Frame and the enable_bdp 262 transport parameter. Parameters are registered using the procedure 263 defined in [RFC9000]. 265 6. Security Considerations 267 Security considerations are discussed in Section 3. 269 7. References 271 7.1. Normative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, 275 DOI 10.17487/RFC2119, March 1997, 276 . 278 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 279 "Framework for TCP Throughput Testing", RFC 6349, 280 DOI 10.17487/RFC6349, August 2011, 281 . 283 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 284 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 285 May 2017, . 287 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 288 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 289 . 291 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 292 Multiplexed and Secure Transport", RFC 9000, 293 DOI 10.17487/RFC9000, May 2021, 294 . 296 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 297 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 298 . 300 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 301 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 302 May 2021, . 304 7.2. Informative References 306 [I-D.cardwell-iccrg-bbr-congestion-control] 307 Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V. 308 Jacobson, "BBR Congestion Control", Work in Progress, 309 Internet-Draft, draft-cardwell-iccrg-bbr-congestion- 310 control-01, 7 November 2021, 311 . 314 Authors' Addresses 316 Nicolas Kuhn 317 Email: nicolas.kuhn.ietf@gmail.com 319 Emile Stephan 320 Orange 321 Email: emile.stephan@orange.com 322 Godred Fairhurst 323 University of Aberdeen 324 Department of Engineering 325 Fraser Noble Building 326 Aberdeen 327 Email: gorry@erg.abdn.ac.uk 329 Tom Jones 330 University of Aberdeen 331 Department of Engineering 332 Fraser Noble Building 333 Aberdeen 334 Email: tom@erg.abdn.ac.uk 336 Christian Huitema 337 Private Octopus Inc. 338 Email: huitema@huitema.net