QUIC Q. Misell Internet-Draft AS207960 Intended status: Standards Track 22 January 2024 Expires: 25 July 2024 QUIC Bandwidth Delay Product Tokens draft-misell-quic-bdp-token-02 Abstract 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. Discussion This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/theenbyperor/quic-bdp-token. Status of This Memo 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 25 July 2024. Copyright Notice Copyright (c) 2024 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. Misell Expires 25 July 2024 [Page 1] Internet-Draft QUIC BDP Tokens January 2024 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. BDP Tokens . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Client interaction . . . . . . . . . . . . . . . . . . . 4 2.2. Invalid BDP tokens . . . . . . . . . . . . . . . . . . . 4 3. Extension signalling . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4.1. QUIC Transport Parameters . . . . . . . . . . . . . . . . 5 4.2. QUIC Transport Error Codes . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction 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 change in the BDP of the path. 1.1. Requirements Language 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. 2. BDP Tokens The address validation token is overloaded to also store Congestion Control information. This has the neat 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 to the token, whilst still providing fields for server specific Misell Expires 25 July 2024 [Page 2] Internet-Draft QUIC BDP Tokens January 2024 information that is opaque to the client. The format of a token containing BDP information is defined as follows: BDP Token { Address Validation Length (i), Address Validation (..), Congestion Control Data Length (i), Congestion Control Data Value (..), Capacity (i), RTT (i), Requested Capacity (i) } Figure 1: BDP Token The fields are as follows: Address Validation Length A variable-length integer specifying the length of the Address Validation field, in bytes. A value of 0 indicates that the server is not using address validation and is using the token purely for CC information. Address Validation Opaque information specific to the server that it will use for address validation. The construction of this field MUST comply with the requirements of QUIC [RFC9000] section 8.1. Congestion Control Data Length A variable-length integer specifying the length of the Congestion Control Data field, in bytes. A value of 0 indicates that the server does not intend to store Congestion Control data on the client, and that the Saved Capacity and Saved RTT fields are merely informative. Congestion Control Data Opaque information specific to the server that it will use to prime its congestion controller state. This field SHOULD contain expiration/lifetime information, and any additional information that the server may need to validate that the same path is being used, such as an endpoint token as defined in Careful Resume [I-D.ietf-tsvwg-careful-resume]. The data MUST be signed, or otherwise protected against modification by the client. Capacity The estimated capacity of the path in bytes, encoded as a variable-length integer. The exact Congestion Control state value used to fill this field is left to server preference. RTT The RTT of the path in microseconds, encoded as a variable- Misell Expires 25 July 2024 [Page 3] Internet-Draft QUIC BDP Tokens January 2024 length integer. The exact Congestion Control state value used to fill this field is left to server preference. Requested Capacity In a token sent by the server, this field is set to the same value as the Capacity field. If the client becomes aware of a change in the available bandwidth of the path, it can adjust this field to request a lower capacity be used by the server when priming its congestion controller state. 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. 2.1. Client interaction If the client becomes aware of a change in the available bandwidth of the path, it can use the Requested Capacity field to signal to the server a change it its available bandwidth. The server MUST not accept a value higher than that of the Capacity field, as this could cause an overload of the network path. If the client sets the Requested Bandwidth field to 0 then it is signalling that the server should not attempt to prime its congestion controller from previous state and should instead treat this connection as an entirely new congestion control context. 2.2. Invalid BDP tokens If the server is unable to decode the token received from the client as a valid BDP token then this MUST be treated as a connection error BDP_TOKEN_ERROR (0x4143414213370002). A token which is merely expired MUST NOT trigger a connection error, instead it should be silently discarded. 3. Extension signalling 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. bdp_token (0x4143414213370002) The bdp_token transport parameter is a boolean value that indicates that the server is using BDP tokens. It can have the following values: - 0, default value: BDP Tokens are not in use. - 1: BDP Tokens are in use. Misell Expires 25 July 2024 [Page 4] Internet-Draft QUIC BDP Tokens January 2024 4. IANA Considerations 4.1. QUIC Transport Parameters 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 | +====================+=============+===============+================+ | 0x4143414213370002 | Provisional | This document | bdp_frame | +--------------------+-------------+---------------+----------------+ Table 1: New entries 4.2. QUIC Transport Error Codes Per this document, one new entry has been added to the "QUIC Transport Error Codes" registry defined in [RFC9000] section 22.5. This entry is defined below: +==================+===========+===============+===========+=============+ |Value |Status |Code |Description|Specification| +==================+===========+===============+===========+=============+ |0x4143414213370002|Provisional|BDP_TOKEN_ERROR|The BDP |This document| | | | |token | | | | | |received | | | | | |from the | | | | | |client is | | | | | |invalid. | | +------------------+-----------+---------------+-----------+-------------+ Table 2: New entries 5. Security Considerations The Congestion Control Data field MUST be protected against manipulation by malicious or mis-behaving clients. A client that can modify Congestion Control calculations could cause an 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 these when processing a received BDP token. 6. References Misell Expires 25 July 2024 [Page 5] Internet-Draft QUIC BDP Tokens January 2024 6.1. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . 6.2. Informative References [I-D.ietf-tsvwg-careful-resume] Kuhn, N., Emile, S., Fairhurst, G., and C. Huitema, "Convergence of Congestion Control from Retained State", Work in Progress, Internet-Draft, draft-ietf-tsvwg- careful-resume-04, 24 October 2023, . Author's Address Q Misell AS207960 Cyfyngedig 13 Pen-y-lan Terrace Caerdydd CF23 9EU United Kingdom Email: q@as207970.net, q@magicalcodewit.ch URI: https://magicalcodewit.ch Misell Expires 25 July 2024 [Page 6]