HTTP Datagram PING and TIMESTAMP

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 27 November 2022.¶

Copyright Notice

Copyright (c) 2022 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.¶

Table of Contents

1. Conventions and Definitions

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2. PING

PING Datagrams can be used to characterize and monitor the end-to-end HTTP Datagram path associated with an HTTP request. For example, HTTP endpoints can easily use PING Datagrams to estimate the round-trip time and loss rate of the HTTP Datagram path.¶

PING Datagrams are also suitable for use as DPLPMTUD Probe Packets [RFC8899]. This enables endpoints to estimate the HTTP Datagram MTU of each request-response pair, in order to avoid sending HTTP Datagrams that will be dropped.¶

Note that these path characteristics can differ from those inferred from the underlying transport (e.g. QUIC), if the HTTP request traverses one or more HTTP intermediaries (see Section 3.7 of [I-D.draft-ietf-httpbis-semantics]).¶

PING Datagram {
  Context ID (i),
  Sequence Number (i),
  Opaque Data (..),
}

3. TIMESTAMP

The TIMESTAMP Datagram extension allows marking any datagram with a timestamp indicating the time that it was sent. Where PING allows measurement of the round-trip time between peers, TIMESTAMP allows peers to observe changes in the one-way latency. Increasing one-way latency can indicate congestion on that path, informing peers' congestion control decisions.¶

REGISTER_TIMESTAMP_CONTEXT Capsule {
  Context ID (i)
  Inner Context ID (i)
  Short Format (1)
}

ACK_TIMESTAMP_CONTEXT Capsule {
  Context ID (i)
  Error Code (i)
}

CLOSE_TIMESTAMP_CONTEXT Capsule {
  Context ID (i)
}

TIMESTAMP Datagram {
  Context ID (i),
  Timestamp (32..64),
  Inner Data (..),
}

4. Examples

This example shows the PING and TIMESTAMP types used in combination. Note that the client is using a "false start" pattern, creating and using two registrations before either is confirmed.¶

Client                                                          Origin

# Headers
Capsule-Protocol: ?1
DG-Timestamp: ?1
DG-Ping: 42

# Capsules
REGISTER_TIMESTAMP_CONTEXT(Context ID = 6, Inner ID = 42, Short = 1) ==>

# Datagrams
[Context ID(6) + Timestamp(X) + Sequence Number(0) + Opaque Data] --->

# Headers
                                                   Capsule-Protocol: ?1
                                                   DG-Timestamp: ?1
                                                   DG-Ping: 42

# Capsules
              <== ACK_TIMESTAMP_CONTEXT(Context ID = 6, Error Code = 0)

# Datagrams
               <--- [Context ID(6) + Timestamp(Y) + Sequence Number(1)]

TIMESTAMP can also be applied to other payload types, such as UDP packets. In CONNECT-UDP, these are pre-allocated with Context ID 0. This example similarly shows a "false start" pattern, sending a datagram before its context registration, or support for this format, is confirmed.¶

Client                                               CONNECT-UDP Server

# Headers
:method = CONNECT
:protocol = connect-udp
Capsule-Protocol: ?1
DG-Timestamp: ?1

# Capsules
REGISTER_TIMESTAMP_CONTEXT(Context ID = 2, Inner ID = 0, Short = 1) ==>

# Datagrams
[Context ID(2) + Timestamp(X) + UDP Payload] --->

# Headers
                                                   Capsule-Protocol: ?1
                                                   DG-Timestamp: ?1

# Capsules
              <== ACK_TIMESTAMP_CONTEXT(Context ID = 2, Error Code = 0)

# ... server waits for a UDP response packet.
# Datagrams
                      <--- [Context ID(2) + Timestamp(Y) + UDP Payload]

5. IANA considerations

Acknowledgments

Thanks to Alex Chernyakhovsky for constructive input.¶

Author's Address