QUIC Bandwidth Delay Product Tokens

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.¶

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 significant change in the BDP of the path.¶

2. BDP Tokens

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:¶

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 [RFC9000] section 8.1.¶

CC Data Length

A variable-length integer specifying the length of the CC Data field, in bytes. A value of 0 indicates that the server is not using CC Data, and that the Saved Capacity and Saved RTT fields should also be ignored.¶

CC 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 defined in [I-D.ietf-tsvwg-careful-resume]. The data MUST be signed, or otherwise processed against modification by the client.¶

Capacity

The estimated capacity of the path in bytes, encoded as a variable-length integer. The exact CC state value used is left to server preference.¶

RTT

The RTT of the path in microseconds, encoded as a variable-length integer. The exact CC state value used is left to server preference.¶

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.¶

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 (0xTBD)

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.¶

6. References