]> Google LLC

bemasc@google.com

General masque Internet-Draft This draft defines new mechanisms for measuring the functionality and performance of an HTTP Datagram path. These mechanisms can be used with CONNECT-UDP, CONNECT-IP, or any other instantiation of the Capsule Protocol. 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 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 . 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 ).

Registration Endpoints indicate support for the PING Datagram type using the Item Structured Field "DG-Ping" in the HTTP Request and Response headers. Its value MUST be an integer indicating the Context ID allocated for PING datagrams. (See for information about the integer format.) Endpoints MUST NOT allocate more than one Context ID for PING Datagrams. As a side effect, this means that only the HTTP client can choose the Context ID used for PING Datagrams.

Format PING Datagrams have the following 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.

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.

Registration Endpoints indicate support for TIMESTAMP Datagram type by including the boolean-valued Item Structured Field "DG-Timestamp: ?1" in the HTTP Request and Response headers. (See for information about the boolean format.) A TIMESTAMP Datagram context is opened by a REGISTER_TIMESTAMP_CONTEXT Capsule with the following structure: "Inner Context ID" specifies how to interpret the payload after the timestamp. It MUST be smaller than "Context ID", and MUST already be registered (although that registration does not need to have been confirmed yet). If "Short Format" is 1 (i.e. true), timestamps MUST use the NTP Short Format (). Otherwise, the full NTP Timestamp Format MUST be used. Registration is confirmed by an ACK_TIMESTAMP_CONTEXT Capsule: Error Code 0 means registration succeeded. Error Code 1 means registration failed. All other error code values also mean failure, but they are reserved for future use. Registrations can be closed by a CLOSE_TIMESTAMP_CONTEXT Capsule: Endpoints SHOULD close any TIMESTAMP context before closing its Inner Context. If the Inner Context is closed first, datagrams subsequently received on the TIMESTAMP context MUST be dropped.

Format TIMESTAMP Datagrams have the following format: "Timestamp" is an NTP timestamp in the short or full format, as specified at registration. The NTP Short Format occupies 4 bytes and provides a resolution of 15 microseconds; the full NTP Timestamp Format occupies 8 bytes and provides a resolution of 232 picoseconds. "Inner Data" is a payload to be interpreted in accordance with this context's "Inner Context ID".

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.

TIMESTAMP and PING example # 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.

TIMESTAMP and UDP example # 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] ]]>

IANA considerations

Capsule types IANA is directed to add the following entries to the "HTTP Capsule Types" registry:

Capsule Type	Value	Specification
REGISTER_TIMESTAMP_CONTEXT	TBD	(This document)
ACK_TIMESTAMP_CONTEXT	TBD	(This document)
CLOSE_TIMESTAMP_CONTEXT	TBD	(This document)

HTTP headers IANA is directed to add the following entries to the "Hypertext Transfer Protocol (HTTP) Field Name Registry":

Field Name	Template	Status	Reference	Comments
DG-Ping		permanent	(This document)
DG-Timestamp		permanent	(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. This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK] 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.