Internet DRAFT - draft-misell-quic-bdp-token
draft-misell-quic-bdp-token
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.
<https://www.rfc-editor.org/info/bcp14>
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
careful-resume-04>.
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]
