]> Google LLC

bemasc@google.com

General masque Internet-Draft This draft defines an HTTP Datagram Format Type for measuring the functionality of a Datagram path. Discussion Venues Discussion of this document takes place on the mailing list (masque@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

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 when, and only when, they appear in all capitals, as shown here.

PING Datagram Format Type PING is an HTTP Datagram Format Type . It has no Additional Data.

Format PING Datagrams have the following format:

PING Datagram Format

All Sequence Number and Opaque Data values are potentially valid.

Use The sender emits a PING Datagram with any even Sequence Number and any Opaque Data. Upon receiving a PING Datagram with an even Sequence Number, the recipient MUST reply with a PING Datagram whose Sequence Number is one larger, with empty Opaque Data. Intermediaries MUST forward PING Datagrams without modification, just like any other HTTP Datagram.

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

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

• Type: PING
• Value: TBD
• Reference: (This document)

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Google LLC Cloudflare The QUIC DATAGRAM extension provides application protocols running over QUIC with a mechanism to send unreliable data while leveraging the security and congestion-control properties of QUIC. However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts. This document describes how to use QUIC DATAGRAM frames when the application protocol running over QUIC is HTTP/3. It associates datagrams with client-initiated bidirectional streams and defines an optional additional demultiplexing layer. Additionally, this document defines how to convey datagrams over prior versions of HTTP. Informative References This document specifies Datagram Packetization Layer Path MTU Discovery (DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet black hole. It can also probe a network path to discover whether the maximum packet size can be increased. This provides functionality for datagram transports that is equivalent to the PLPMTUD specification for TCP, specified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines to refer to this method for use with UDP datagrams and updates SCTP. The document provides implementation notes for incorporating Datagram PMTUD into IETF datagram transports or applications that use datagram transports. This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, and RFC 8261. Adobe Fastly greenbytes GmbH The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230.

Acknowledgments Thanks to Alex Chernyakhovsky for constructive input.