idnits 2.17.1 draft-kuhn-quic-0rtt-bdp-11.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 (23 October 2021) is 909 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. Kuhn 3 Internet-Draft CNES 4 Intended status: Informational E. Stephan 5 Expires: 26 April 2022 Orange 6 G. Fairhurst 7 T. Jones 8 University of Aberdeen 9 C. Huitema 10 Private Octopus Inc. 11 23 October 2021 13 Transport parameters for 0-RTT connections 14 draft-kuhn-quic-0rtt-bdp-11 16 Abstract 18 QUIC 0-RTT transport features currently focuses on egress traffic 19 optimization. This draft describes a QUIC extension that can be used 20 to improve the performance of ingress traffic. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 26 April 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Notations and terms . . . . . . . . . . . . . . . . . . . 4 57 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 58 2. Safe jump start . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Rationale behind the safety guidelines . . . . . . . . . 5 60 2.2. Rationale #1: Variable network conditions . . . . . . . . 6 61 2.3. Rationale #2: Malicious clients . . . . . . . . . . . . . 7 62 2.4. Trade-off between the different solutions . . . . . . . . 8 63 2.4.1. Security aspects . . . . . . . . . . . . . . . . . . 8 64 2.4.2. Interoperability and use-cases . . . . . . . . . . . 8 65 2.4.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 9 66 3. Safety guidelines . . . . . . . . . . . . . . . . . . . . . . 10 67 4. Implementation considerations . . . . . . . . . . . . . . . . 12 68 4.1. Rationale behind the different implementation options . . 12 69 4.2. Independent local storage of values . . . . . . . . . . . 12 70 4.3. Using NEW_TOKEN frames . . . . . . . . . . . . . . . . . 13 71 4.4. BDP Frame . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.4.1. BDP Frame Format . . . . . . . . . . . . . . . . . . 13 73 4.4.2. Extension activation . . . . . . . . . . . . . . . . 14 74 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 5.1. BDP extension protected as much as initial_max_data . . . 15 76 5.2. Other use-cases . . . . . . . . . . . . . . . . . . . . . 15 77 5.2.1. Optimizing client's requests . . . . . . . . . . . . 15 78 5.2.2. Sharing transport information across multiple 79 connections . . . . . . . . . . . . . . . . . . . . . 16 80 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 85 9.2. Informative References . . . . . . . . . . . . . . . . . 17 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 88 1. Introduction 90 QUIC 0-RTT transport features currently focus on egress traffic 91 optimization. This draft describes a QUIC extension that can be used 92 to improve the performance of ingress traffic. 94 [RFC9000] mentions that "Generally, implementations are advised to be 95 cautious when using previous values on a new path." This draft 96 proposes a discussion on how using previous values can be achieved in 97 a interoperable manner and how it can be done safely. 99 When clients resume a session to download a large object, the 100 congestion control algorithms will require time to ramp-up the packet 101 rate as a sequence of Round-Trip Time (RTT)-based increases. This 102 document specifies a method that can improve traffic delivery by 103 allowing a QUIC connection to avoid a the slow process to discover 104 key path parameters including a way to more rapidly grow the 105 congestion window (cwnd): 107 1. During a previous session, current RTT (current_rtt), bottleneck 108 bandwidth (current_bb) and current client IP (current_client_ip) 109 are stored as saved_rtt, saved_bb and saved_client_ip; 111 2. When resuming a session to the same IP address, the server can 112 then utilize the current_rtt and the current_bb to the saved_rtt 113 and saved_bb of a previous connection. 115 This method applies to any resumed QUIC session: both saved_session 116 and recon_session can be a 0-RTT QUIC connection or a 1-RTT QUIC 117 connection. 119 The current version of this draft considers several possible 120 solutions: (1) the saved parameters are stored at the server; they 121 are not sent to the client; (2) the saved parameters are sent to the 122 client as an encrypted opaque blob; although the client is unable to 123 read the parameters can include this opaque blob in a subsequent 124 request to the server; (3) the saved parameters are sent to the 125 client and the client is notified of their value, but the parameters 126 also include a cryptographic integrity check; the client can include 127 both the parameters and the integrity check in a subsequent request 128 to the server. 130 None of these possible solutions allow q client to modify the 131 parameters that will be used by the server. 133 There are several cases where the parameters of a previous session 134 are not appropriate. These include: 136 (1) the network conditions have changed and the current capacity 137 is less than the previously estimated bottleneck bandwidth. Using 138 the saved congestion control state would increase congestion; 139 (2) the network path has changed and the new path is different. 140 Using the saved congestion control state could increase 141 congestion. This case might be accompanied by a change in the RTT 142 or IP address. 144 (3) a client uses parameters that are no longer appropriate, e.g., 145 to intentionally try to use a CWND larger than appropriate. 147 This document: 149 1. proposes guidelines for how to safely apply the previously 150 computed parameters to new sessions; 152 2. describes different implementation considerations for the 153 proposed method using QUIC; 155 3. discusses the trade-offs associated with the different 156 implementation solutions. 158 1.1. Notations and terms 160 * IW: Initial Window (e.g., from [RFC6928]); 162 * current_iw: Current Initial Window 164 * recom_iw: Recommended Initial Window 166 * BDP: defined below 168 * CWND: the congestion window used by server (maximum number of 169 bytes allowed in flight by the CC) 171 * current_bb : Current estimated bottleneck bandwidth 173 * saved_bb: Estimated bottleneck bandwidth preserved from a previous 174 connection 176 * RTT: Round-Trip Time 178 * current_rtt: Current RTT 180 * saved_rtt: RTT preserved from a previous connection 182 * client_ip : IP address of the client 184 * current_client_ip : Current IP address of the client 185 * saved_client_ip : IP address of the client preserved from a 186 previous connection 188 * remembered BDP parameters: a combination of saved_rtt and saved_bb 190 * ITT : Interpacket Transmission Time 192 * MSS : Maximum Message Size 194 * AEAD : Authenticated Encryption with Associated Data 196 * LRU : Least Recently Used 198 [RFC6349] defines the BDP as follows: "Derived from Round-Trip Time 199 (RTT) and network Bottleneck Bandwidth (BB), the Bandwidth-Delay 200 Product (BDP) determines the Send and Received Socket buffer sizes 201 required to achieve the maximum TCP Throughput." This draft 202 considers the BDP estimated by a server that includes all buffering 203 along the network path. In that sense, the BDP estimated is related 204 to the amount of bytes in flight. 206 A QUIC connection might not reproduce the procedure detailed in 207 [RFC6349] to measure the BDP. A server might be able to exploit an 208 internal evaluation of the Bottleneck Bandwidth to estimate the BDP. 210 This document refers to the saved_bb and current_bb for the 211 previously estimated bottleneck bandwidth. This value can be easilly 212 estimated when using a rate-based congestion controller, such as BBR. 213 Other congestion controllers, such as CUBIC or RENO, could estimate 214 the bottleneck bandwidth by utilizing a combinatioin of the cwnd and 215 the minimum RTT. This approach could result in over estimating the 216 bottleneck bandwidth and ought to be used with caution. 218 1.2. Requirements Language 220 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 222 "OPTIONAL" in this document are to be interpreted as described in BCP 223 14 [RFC2119] [RFC8174] when, and only when, they appear in all 224 capitals, as shown here. 226 2. Safe jump start 228 2.1. Rationale behind the safety guidelines 230 The previously measured saved_rtt and saved_bb SHOULD NOT be used as- 231 is, to avoid potential congestion collapse: 233 * Rationale #1: Internet path capacity can change at any time. An 234 Internet method needs to be robust to network conditions that can 235 differ from one session to the next. 237 * Rationale #2: Information sent by a malicious client is not 238 relevant. A client could try to convince a server to use a CWND 239 higher than appropriate, to gain an unfair share of capacity for 240 itself or to induce congestion for other flows. 242 2.2. Rationale #1: Variable network conditions 244 The server MUST check the validity of the saved_rtt and saved_bb 245 parameters, whether these are sent by a client or are stored at the 246 server. The following events indicates cases where use of these 247 parameters is inappropriate: 249 * IP address changed: If the client changes its IP address (i.e. 250 the saved_client_ip is different from the current_client_ip), the 251 different address is to be takne as an indication of a different 252 network path. This new path does not necessarily exhibit the same 253 characteristics as the old one. If the server changes its IP 254 address after a migration, it would not be safe to exploit 255 previously estimated parameters. 257 * RTT changed: A significant change in RTT might be an indication 258 that the the network conditions changed. Since the CC information 259 is directly impacted by the RTT, a significant change in RTT is a 260 strong indication that the previously estimated BDP parameters are 261 likely to not be valid for the current path. 263 * Lifetime of the extension: The CC information is temporal. 264 Frequent connections to the same IP address are likely to track 265 changes, but long-term use of previous values are not appropriate. 267 * BB over estimation: There are cases where using the cwnd would 268 infralte the bottleneck bandwidth. However, at the end of a CC 269 slow start, the value of cwnd can be significantly larger than the 270 value, that the CC finally converges to (after a few more rounds). 271 Directly exploiting such value for the bottleneck bandwidth 272 estimation may be inappropriate. One mitigation could be to 273 restrict to only a fraction (e.g., 1/2) of the previously used 274 cwnd; another mitigation might be to calculate the bottleneck 275 bandwidth based on the flightsize. 277 There are different solutions for the variable network conditions: 279 * Rationale #1 - Solution #1 : When resuming a session, restore the 280 current_bb and current_rtt from the saved_bb and saved_rtt 281 parameters estimated from a previous connection. 283 * Rationale #1 - Solution #2 : When resuming a session, implement a 284 safety check to measure avoid using the saved_bb and saved_rtt 285 parameters to cause congestion over the path. In this case, the 286 current_bb and current_rtt might not be set directly to the 287 saved_bb and saved_rtt: the server might wait for the completion 288 of the safety check before doing so. 290 Section 3 describes various approaches for Rationale #1 - Solution 291 #2. 293 2.3. Rationale #2: Malicious clients 295 The server MUST check the integrity of the saved_rtt and saved_bb 296 parameters received from a client. 298 There are several solutions to avoid attacks by malicious clients: 300 * Rationale #2 - Solution #1 : The server stores a local estimate of 301 the bottleneck bandwidth and RTT parameters as the saved_bb and 302 saved_rtt. 304 * Rationale #2 - Solution #2 : The server sends the estimate of the 305 bottleneck bandwidth and RTT parameters to the client as the 306 saved_bb and saved_rtt. This information is encrypted by the 307 server. The client resends the same encrypted information when 308 resuming a connection. The client can neither read nor modify the 309 saved_rtt and saved_bb parameters. 311 * Rationale #2 - Solution #3 : The server sends an estimate of the 312 saved_rtt and saved_bb parameters to the client. The information 313 includes an integrity protection check. The client can resend the 314 information when resuming a connection. This allows a client to 315 read, but not modify, the saved_rtt and saved_bb parameters. This 316 might enable a client to decide whether the new parameters are 317 appropriate, based on client-side information about the network 318 conidtions or connectivity. 320 Section 4 describes various implementation approaches for each of 321 these solutions using local storage ( Section 4.2 for Rationale #2 - 322 Solution #1), NEW_TOKEN Frame ( Section 4.3 for Rationale #2 - 323 Solution #2), BDP extension Frame ( Section 4.4 for Rationale #2 - 324 Solution #3). 326 2.4. Trade-off between the different solutions 328 This section provides a description of different implementation 329 options and discusses their respective advantages and drawbacks. 330 While there are some discussions for the solutions regarding 331 Rationale #2, the server MUST consider Rationale #1 - Solution #2 and 332 avoid Rationale #1 - Solution #1: the server MUST implement a safety 333 check to measure whether the saved BDP parameters (i.e. saved_rtt and 334 saved_bb) are relevant or check that their usage would not cause 335 excessive congestion over the path. 337 2.4.1. Security aspects 339 The client can send information related to the saved_rtt and saved_bb 340 to the server with the BDP Frame extension using either Rationale #2 341 - Solution #2 or Rationale #2 - Solution #3. However, the server 342 SHOULD NOT trust the client. Indeed, even if 0-RTT packets 343 containing the BDP Frame are encrypted, a client could modify the 344 values within the extension and encrypt the 0-RTT packet. 345 Authentication mechanisms might not guarantee that the values are 346 safe. It is not an easy operation for a client to modify 347 authenticated or encrypted data without this being detected by a 348 server. Modification could be realized by malicious clients. One 349 way to avoid this is for a server to also store the saved_rtt and 350 saved_bb parameters. 352 A malicious client might modify the saved_bb parameter to convince 353 the server to use a larger CWND than appropriate. Using the 354 algorithms proposed in Section 3, the server may reduce any intended 355 harm and can check that part of the information provided by the 356 client are valid. 358 Storing the BDP parameters locally at the server reduces the 359 associated risks by allowing the client to transmit information 360 related to the BDP of the path in the case of a malicious client 361 trying to break the encryption mechanism that it had received. 363 2.4.2. Interoperability and use-cases 365 If the server stores a resumption ticket for each client to protect 366 against replay on a third party IP, it could also store the IP 367 address (i.e. saved_client_ip) and BDP parameters (i.e. saved_rtt 368 and saved_bb) of the previous session of the client. 370 In cases where the BDP Frame extension is exploited, the approach of 371 storing the BDP parameters locally at the server can provide a cross- 372 check of the BDP parameters sent by a client. The server can anyway 373 enable a safe jumpstart, but without the BDP Frame extension. 375 However, the client does not have the choice of accepting to use this 376 or not, and is unable to utilize local knowledge of the network 377 conditions or conenctivity. 379 Storing local values related to the BDP would help in improving the 380 ingress for 0-RTT connections, however, not using a BDP Frame 381 extension could reduce the interest of the approach where (1) the 382 client knows the BDP estimations done at the server, (2) the client 383 decides to accept or reject ingress optimization, (3) the client 384 tunes application level requests. 386 2.4.3. Summary 388 As a summary, the approach of local storage of values can be secure 389 and the BDP Frame extension provides more information to the client 390 and more interoperability. The Figure 1 provides a summary of the 391 advantages and drawbacks of each approach. 393 +---------+-----------+----------------+---------------+-----------+ 394 |Rationale| Solution | Advantage | Drawback | Comment | 395 +---------+-----------+----------------+---------------+-----------+ 396 |#1 |#1 | | | | 397 |Variable |set |Ingress optim. |Risks of adding|MUST NOT | 398 |Network |current_* | | congestion |implement | 399 | |to saved_* | | | | 400 | +-----------+----------------+---------------+-----------+ 401 | |#2 | | | | 402 | |Implement |Reduce risks of |Negative impact|MUST | 403 | |safety | adding | on ingress |implement | 404 | |check | congestion | optim. |Section 3 | 405 +---------+-----------+----------------+---------------+-----------+ 406 |#2 |#1 | | | | 407 |Malicious|Local |Enforced |Client unable | | 408 |client |storage | security | to decide to | | 409 | | | | reject | | 410 | | | |Malicious | | 411 | | | | server could | | 412 | | | | fill client's | | 413 | | | | buffer | | 414 | | | |Limited | | 415 | | | | use-cases |Section 4.2| 416 | +-----------+----------------+---------------+-----------+ 417 | |#2 | | | | 418 | |NEW_TOKEN |Save resource |Malicious | | 419 | | | at server | client could | | 420 | | |Opaque token | change token | | 421 | | | protected | even if | | 422 | | | | protected | | 423 | | | |Malicious | | 424 | | | | server could | | 425 | | | | fill client's | | 426 | | | | buffer | | 427 | | | |Server may not | | 428 | | | | trust client |Section 4.3| 429 | +-----------+----------------+---------------+-----------+ 430 | |#3 | | | | 431 | |BDP |Extended |Malicious | | 432 | |extension | use-cases | client could | | 433 | | |Save resource | change BDP | | 434 | | | at server | even if | | 435 | | |Client can | protected | | 436 | | | read and decide|Server may not | | 437 | | | to reject | trust client | | 438 | | |BDP extension | | | 439 | | | protected | | | 440 | | | | |Section 4.4| 441 +---------+-----------+----------------+---------------+-----------+ 443 Figure 1: Comparing solutions 445 3. Safety guidelines 447 The safety guidelines are designed to avoid a server adding excessive 448 congestion to an already congested path. The following mechanisms 449 help in fulfilling this objective: 451 * The server SHOULD compare the measured transport parameters (in 452 particular current_rtt) of the 0-RTT connection with those of the 453 1-RTT connection (in particular saved_rtt); 455 * The server SHOULD NOT consider the saved_bb parameter when there 456 is any indicated congestion (e.g., loss of packet during the first 457 transmission of data or ECN-CE mark); 459 * The server MUST NOT send more than the recommended maximum IW 460 (recom_iw) in the first transmission of data. This value could be 461 based on a local understanding of the path characteristics. 462 Knowing the congestion status of the network in closed 463 environments may help in increasing the recommended maximum IW. 465 * The server SHOULD NOT store and/or send information related to the 466 previously estimated bottleneck bandwidth (saved_bb) (see 467 Section 1.1 for more details on bottleneck bandwidth definition), 468 if this estimation has not been computed after some rounds during 469 the 1-RTT connection. At least, the 1-RTT connection should have 470 reached the congestion avoidance phase. 472 The proposed mechanisms SHOULD be limited by any rate-limitation 473 mechanisms of QUIC, such as flow control mechanisms or amplification 474 attack prevention. In particular, it may be necessary to issue 475 proactive MAX_DATA frames to increase the flow control limits of a 476 connection. In particular, the maximum number of packets that can be 477 sent without acknowledgment needs to be chosen to avoid the creation 478 and the increase of congestion for the path. 480 This extension should not provide an opportunity for the current 481 connection to be a vector of an amplification attack. The address 482 validation process, used to prevent amplification attacks, SHOULD be 483 performed [RFC9000]. 485 The following mechanisms could be implemented: 487 * Exploit a standard IW: 489 1. The server sends the first data packet using the IW - this is 490 a safe starting point for any path where there is no path 491 information or where there is no congestion state. This 492 avoids adding excessive congestion to the path; 494 2. If the reception of IW exhibits characteristics that resemble 495 those of a recent previous session from the client (i.e. 496 current_rtt < 1.2*saved_rtt and all data was acknowledged 497 without reported congestion), the method permits the sender to 498 consider the saved_bb as an input to adapt current_bb to 499 rapidly determine a new safe rate; 501 3. The sender needs to avoid a burst of packets resulting from a 502 step-increase in the congestion window [RFC9000]. Pacing the 503 packets as a function of the current_rtt can provide this 504 additional safety during the period in which the CWND is 505 increased by the method. 507 * Identify a relevant pacing rhythm: 509 - The server estimates the pacing rhythm using saved_rtt and 510 saved_bb. The Interpacket Transmission Time (ITT) is 511 determined by the ratio between the current Maximum Message 512 Size (MSS) for packets and the ratio between the saved_bb and 513 saved_rtt. A tunable safety margin might be introduced to 514 avoid sending more than a recommended maximum IW (recom_iw): 516 o current_iw = min(recom_iw,saved_bb) 518 o ITT = MSS/(current_iw/saved_rtt) 520 - When the IW is acknowledged, the server falls back to a 521 standard slow-start mechanism. 523 * Tune slow-start mechanisms: After transport parameters are set to 524 a previously estimated bottleneck bandwidth, if slow-start 525 mechanisms continue, the sender can overshoot the bottleneck 526 capacity. This can occur even if the safety check described in 527 this section is implemented. 529 - For NewReno and CUBIC, it is recommended to exit slow-start and 530 enter in congestion avoidance phase. 532 - For BBR, it is recommended to move to the "probe bandwidth" 533 state. 535 This follows the idea of [RFC4782], 536 [I-D.irtf-iccrg-sallantin-initial-spreading] and [CONEXT15]. 538 4. Implementation considerations 540 4.1. Rationale behind the different implementation options 542 The NewSessionTickets messages of TLS offer a solution. The idea 543 would have been to add a 'bdp_metada' field in the NewSessionTickets 544 that the client could read. The sole extension currently defined in 545 TLS1.3 that can be seen by the client is max_early_data_size (see 546 section 4.6.1 of [RFC8446]). However, in the general design of QUIC, 547 TLS sessions are managed by the TLS stacks. 549 Three distinct approaches are presented: sending an opaque blob to 550 the client that it may return to the server for a future connection 551 (see Section 4.3), enable a local storage of BDP related values (see 552 Section 4.2) and a BDP Frame extension (see Section 4.4). 554 4.2. Independent local storage of values 556 This approach independently lets both a client and a server remember 557 their BDP parameters: 559 * During a 1-RTT session, the endpoint stores the RTT (as the 560 saved_rtt) and bottleneck bandwidth (as the saved_bb) together 561 with the session resume ticket. The client can also store the IP 562 address of the server. 564 * The server maintains a table of previously issued tickets, indexed 565 by the random ticket identifier that is used to guarantee 566 uniqueness of the Authenticated Encryption with Associated Data 567 (AEAD) encryption. Old tokens are removed from the table using 568 the Least Recently Used (LRU) logic. For each ticket identifier, 569 the table holds the RTT and bottleneck bandwidth (i.e. saved_rtt 570 and saved_bb), and also the IP address of the client (i.e. 571 saved_client_ip). 573 During the 0-RTT session, the endpoint waits for the first RTT 574 measurement from the peer's IP address. This is used to verify that 575 the current_rtt has not significantly changed from the saved_rtt, and 576 hence is an indication that the BDP information is appropriate to the 577 path that is currently being used. 579 If this RTT is confirmed (e.g. current_rtt < 1.2*saved_rtt, the 580 endpoint also verifies that an initial window of data has been 581 acknowledged without requiring retransmission. This second check 582 detects a path with significant incipient congestion (i.e. where it 583 would not be safe to update the CWND based on the saved_bb). In 584 practice, this could be realized by a proportional increase in the 585 CWND, where the increase is (saved_bb/IW)*proportion_of_IW_currently- 586 ACKed. 588 This solution does not allow the client to refuse the exploitation of 589 the BDP parameters. If the server does not want to store the metrics 590 from previous connections, an equivalent of the tcp_no_metrics_save 591 for QUIC may be necessary. This option could be negociated that 592 alows a client to choose whether to use the saved information. 594 4.3. Using NEW_TOKEN frames 596 Using NEW_TOKEN Frames, the server could send a token to the client 597 through a NEW_TOKEN Frame. The token is an opaque blob and the 598 client can not read its content (see section 19.7 of [RFC9000]). The 599 client sends the received token in the header of an Initial packet 600 for a later connection. 602 4.4. BDP Frame 604 This section describes the use of a new Frame, the BDP Frame. The 605 BDP Frame MUST be contained in 0-RTT packets, if sent by the client. 606 The BDP Frame MUST be contained in 1-RTT packets, if sent by the 607 server. The BDP Frame MUST be considered by congestion control and 608 its data is not be limited by flow control limits. The server MAY 609 send multiple BDP Frames in both 1-RTT and 0-RTT connections. The 610 client can send BDP Frames during 1-RTT and 0-RTT connections. 612 4.4.1. BDP Frame Format 614 A BDP Frame is formatted as shown in Figure 2. 616 BDP Frame { 617 Type (i) = 0xXXX, 618 Lifetime (i), 619 Saved BB (i), 620 Saved RTT (i), 621 Saved IP length (i), 622 Saved IP (...) 623 } 625 Figure 2: BDP Frame Format 627 A BDP Frame contains the following fields: 629 * Lifetime (extension_lifetime): The extension_lifetime is a value 630 in milliseconds, encoded as a variable length integer. This 631 follows the idea of NewSessionTicket of TLS [RFC8446]. This 632 represents the validity in time of this extension. 634 * Saved BB (saved_bb): The saved_bb is a value in bytes, encoded as 635 a variable length integer. The bottleneck bandwidth estimated for 636 the previous connection by the server. Using the previous values 637 of bytes_in_flight defined in [RFC9002] can result in overshoot of 638 the bottleneck capacity and is not advised. 640 * Saved RTT (saved_rtt): The saved_rtt is a value in milliseconds, 641 encoded as a variable length integer. This could be set to the 642 minimum RTT (min_rtt). The saved_rtt can be set to min_rtt. 643 NOTE: The min_rtt defined in [RFC9002], does not track a 644 decreasing RTT: therefore min_rtt reported might be larger than 645 the actual minimum RTT measured during the 1-RTT connection. 647 * Saved IP length (saved_ip_length) : The length of the IP address 648 set to either 4 (IPv4) or 16 (IPv6). 650 * Saved IP (saved_client_ip) : The saved_client_ip could be set to 651 the IP address of the client. 653 4.4.2. Extension activation 655 The client can accept the transmission of BDP Frames from the server 656 by using the enable_bdp transport extension. 658 enable_bdp (0xTBD): in the 1-RTT connection, the client indicates to 659 the server that it wishes to receive BDP extension Frames for 660 improving ingress of 0-RTT connection. The default value is 0. 661 Values strictly above 3 are invalid, and receipt of these values MUST 662 be treated as a connection error of type TRANSPORT_PARAMETER_ERROR. 664 * 0: Default value. If the client does not send this parameter, the 665 server considers that the client does not support or does not wish 666 to activate the BDP extension. 668 * 1: The client indicates to the server that it wishes to receive 669 BDP Frame and activates the ingress optimization for the 0-RTT 670 connection. 672 * 2: The client indicates that it does not wish to receive BDP 673 Frames but activates ingress optimization. 675 * 3: The client indicates that it wishes to receive BDP Frames but 676 does not activate ingress optimization. 678 This Transport Parameter is encoded as per Section 18 of [RFC9000]. 680 5. Discussion 682 5.1. BDP extension protected as much as initial_max_data 684 The BDP metadata parameters are measured by the server during a 685 previous connection. The BDP extension is protected by the mechanism 686 that protects the exchange of the 0-RTT transport parameters. For 687 version 1 of QUIC, the BDP extension is protected using the mechanism 688 that already protects the "initial_max_data" parameter. This is 689 defined in sections 4.5 to 4.7 of [RFC9001]. This provides a way for 690 the server to verify that the parameters proposed by the client are 691 the same as those that the server sent to the client during the 692 previous connection. 694 5.2. Other use-cases 696 5.2.1. Optimizing client's requests 698 When using Dynamic Adaptive Streaming over HTTPS (DASH), clients 699 might encounter issues in knowing the available path capacity or DASH 700 can encounter issues in reaching the best available video playback 701 quality. The client requests could then be adapted and specific 702 traffic could utilize information from the path characteristics (such 703 as encouraging the client to increase the quality of video chunks, to 704 fill the buffers and avoid video blocking or to send high quality 705 adds). 707 In other cases, applications could provide additional services if 708 clients can know the server estimation of the path characteristics. 710 5.2.2. Sharing transport information across multiple connections 712 There can be benefit in sharing transport information across multiple 713 connections. [I-D.ietf-tcpm-2140bis] considers the sharing of 714 transport parameters between TCP connections originating from the 715 same host. The proposal in this document has the advantage of 716 storing server-generated information at the client and not requiring 717 the server to retain additional state for each client. 719 6. Acknowledgments 721 The authors would like to thank Gabriel Montenegro, Patrick McManus, 722 Ian Swett, Igor Lubashev, Robin Marx, Roland Bless and Franklin Simo 723 for their fruitful comments on earlier versions of this document. 725 7. IANA Considerations 727 TBD: Text is required to register the BDP Frame and the enable_bdp 728 transport parameter. Parameters are registered using the procedure 729 defined in [RFC9000]. 731 8. Security Considerations 733 Security considerations are discussed in Section 5 and in Section 3. 735 9. References 737 9.1. Normative References 739 [I-D.ietf-tcpm-2140bis] 740 Touch, J., Welzl, M., and S. Islam, "TCP Control Block 741 Interdependence", Work in Progress, Internet-Draft, draft- 742 ietf-tcpm-2140bis-11, 12 April 2021, 743 . 746 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 747 Requirement Levels", BCP 14, RFC 2119, 748 DOI 10.17487/RFC2119, March 1997, 749 . 751 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 752 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, 753 January 2007, . 755 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 756 "Framework for TCP Throughput Testing", RFC 6349, 757 DOI 10.17487/RFC6349, August 2011, 758 . 760 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 761 "Increasing TCP's Initial Window", RFC 6928, 762 DOI 10.17487/RFC6928, April 2013, 763 . 765 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 766 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 767 May 2017, . 769 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 770 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 771 . 773 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 774 Multiplexed and Secure Transport", RFC 9000, 775 DOI 10.17487/RFC9000, May 2021, 776 . 778 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 779 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 780 . 782 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 783 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 784 May 2021, . 786 9.2. Informative References 788 [CONEXT15] Li, Q., Dong, M., and P B. Godfrey, "Halfback: Running 789 Short Flows Quickly and Safely", ACM CoNEXT , 2015. 791 [I-D.irtf-iccrg-sallantin-initial-spreading] 792 Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput, 793 E., and A. Beylot, "Safe increase of the TCP's Initial 794 Window Using Initial Spreading", Work in Progress, 795 Internet-Draft, draft-irtf-iccrg-sallantin-initial- 796 spreading-00, 15 January 2014, 797 . 800 Authors' Addresses 801 Nicolas Kuhn 802 CNES 804 Email: nicolas.kuhn.ietf@gmail.com 806 Emile Stephan 807 Orange 809 Email: emile.stephan@orange.com 811 Godred Fairhurst 812 University of Aberdeen 813 Department of Engineering 814 Fraser Noble Building 815 Aberdeen 817 Email: gorry@erg.abdn.ac.uk 819 Tom Jones 820 University of Aberdeen 821 Department of Engineering 822 Fraser Noble Building 823 Aberdeen 825 Email: tom@erg.abdn.ac.uk 827 Christian Huitema 828 Private Octopus Inc. 830 Email: huitema@huitema.net