Internet-Draft | QUIC BDP Tokens | November 2023 |
Misell | Expires 19 May 2024 | [Page] |
This document describes a method to store previously calculated Congestion Control parameters on a QUIC client to allow additional capacity on high Bandwidth Delay Product paths to be used with Careful Resume.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 May 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document describes a method for a QUIC server to send calculated Congestion Control parameters to a client for storage and later use on a future connection with Careful Resume [I-D.ietf-tsvwg-careful-resume]. It also allows the client to inspect CC parameters, and allows the client not use them with new connections if its aware of a significant change in the BDP of the path.¶
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [BCP14] when, and only when, they appear in all capitals, as shown here.¶
The address validation token is overloaded to also store CC information. This has the advantage that a QUIC client unaware of this document will still be able to make use of this specification without modification. QUIC[RFC9000] defines an address validation token as an opaque blob that the client should not inspect. This document extends this by providing some structure token, whilst still providing fields for server specific information.¶
The format of a token containing BDP information is defined as follows:¶
BDP Token { Address Validation Length (i), Address Validation (..), BDP Data Length (i), BDP Data Value(..), Saved Capacity (i), Saved RTT (i) }
The fields are as follows:¶
The Capacity and RTT fields are merely hints to the client and the server MUST not use these fields when priming its congestion controller state. If it wishes to use these parameters it will have to also include them in its CC Data structure, as data in this field is protected against modification by the client.¶
The server can send the above extended BDP token to all clients without further negotiation. However a client needs some way to know that there is meaningful structure to a token its received from the server. To this end a new transport parameter is defined.¶
Per this document, one new entry has been added to the "QUIC Transport Parameters" registry defined in [RFC9000] section 22.3. This entry is defined below:¶
Value | Status | Specification | Parameter name |
---|---|---|---|
0xTBD | Provisional | This document | bdp_frame |
The CC Data field MUST be protected against manipulation by malicious clients. A client that can modify CC calculations could otherwise cause overload of the network path.¶
The Capacity and RTT fields are hints to the client and not protected from modification by a client. The server MUST ignore when processing a received BDP token.¶