QUIC Bandwidth Delay Product Tokens
draft-misell-quic-bdp-token-02

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]