Internet-Draft HTTP Datagram PING September 2021
Schwartz Expires 25 March 2022 [Page]
Intended Status:
Standards Track
B. Schwartz
Google LLC

HTTP Datagram PING


This draft defines an HTTP Datagram Format Type for measuring the functionality of a Datagram path.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the mailing list (, which is archived at

Source for this draft and an issue tracker can be found at

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

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 March 2022.

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 Datagram Format Type

PING is an HTTP Datagram Format Type [I-D.draft-ietf-masque-h3-datagram].

2.1. Format

PING Datagrams have the following format:

  Sequence Number (i),
  Opaque Data (..),
Figure 1: PING Datagram Format

The Opaque Data field contents are unconstrained.

2.2. Use

We define the "Requester" as the peer that registered this PING Datagram Context, and the "Responder" as the other peer.

The Requester initiates a ping by sending a PING Datagram with any Sequence Number and Opaque Data. The Responder MUST reply with a PING Datagram in the same context, with the same Sequence Number and empty Opaque Data.

Intermediaries MUST forward PING Datagrams without modification, just like any other HTTP Datagram.

3. Use cases

PING Datagrams can be used to characterize 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 Datagram path, 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]).

4. IANA considerations

IANA is directed to add the following entry to the "HTTP Datagram Format Types" registry:

5. References

5.1. Normative References

Schinazi, D. and L. Pardue, "Using Datagrams with HTTP", Work in Progress, Internet-Draft, draft-ietf-masque-h3-datagram-03, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

5.2. Informative References

Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Semantics", Work in Progress, Internet-Draft, draft-ietf-httpbis-semantics-19, , <>.
Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, , <>.



Author's Address

Benjamin Schwartz
Google LLC