]> Haivision Network Video, GmbH

maxsharabayko@haivision.com

Haivision Network Video, GmbH

msharabayko@haivision.com

applications moq media over quic metrics This document defines an approach of objectively measuring transmission such metrics like delay, jitter, and loss-related transmission metrics for a QUIC connection using an artificially generated payload of a specific structure. The measurement is to be carried on an application level to be protocol-independent.

Introduction Establishment of the Media over QUIC working group acknowledges the relevance of live media contribution and distribution and encourages discussions on the use cases to be considered . Several proposals complement to those discussions. Most are currently based on QUIC streams , , , . QUIC datagrams are yet to be considered within the group, but some related work includes , , . Thus, an important task is to evaluate solutions and algorithms being proposed. For example for live media contribution, where processing of data takes place in real time, it is important to estimate transmission delay and delay variation (or jitter), to determine data loss and reordering, as well as to calculate other transmission metrics. The lower the observed jitter level is, the smaller is the decoder buffer needed, and the higher is the confidence in an expected transmission latency. The current draft discusses an approach of objectively measuring transmission delay, jitter, and other performance metrics for any media protocol over a QUIC connection using an artificially generated payload of a specific structure . Both streams and unreliable datagrams are to be supported. However, it is important to highlight the difference between the two. Thus a sub goal is to try to find a universal approach to evaluate performance metrics for both streams and datagrams, providing a common basis for comparison. To be independent from a media protocol over QUIC, the measurement is to be carried on an application level, probably involving QUIC-level statistics where needed. This approach could be used during development of the Media over QUIC protocol to:

• compare the independent proposals and implementations of the Media over QUIC protocol,
• perform regression testing of a certain implementation or proposal,
• evaluate various congestion control schemes for live media,
• maybe compare Media over QUIC protocol performance against other protocols, e.g. RTP over QUIC or SRT .

QUIC, as a protocol, provides a powerful set of statistics which can be used in addition to the defined procedure. There are, however, several things to keep in mind:

• Independent QUIC transport implementations do not necessarily support the same set of statistics and the format isn't necessarily the same among different libraries. Although might be helpful in a way.
• QUIC packets themselves do not have a timestamp field to allow the measurement of one-way delays. Although there is a related draft proposal , which proposes the definition of a TIMESTAMP frame.

Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

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.

Payload Format A payload of a specific format MUST be artificially generated to enable the calculation of performance metrics at the receiver side. The artificially generated payload by its size SHOULD roughly represent a media unit that a hypothetical decoder can decode. For example, in case of a video stream, one payload can represent the whole frame or a slice of that frame that a decoder can process. The arrival of the whole frame forms the actual delay for a viewer/decoder. Even if a frame is partially received earlier, it will be decoded and presented with the reception of a last macroblock or with dropping of the remaining parts of the frame. The artificially generated payload MUST provide means of estimating transmission delay and full or partial loss of the payload. The artificially generated payload SHOULD be of a variable length to represent different sizes of various types of payload and various types of video frames (I, P, B). The approach MUST provide a common basis for comparison independent (or as independent as possible) of whether QUIC streams or datagrams are used as a transport.

Payload Structure

Payload Sequence Number: 64 bits.

A sequential number of the payload. Starts from zero and is incremented for every payload that follows.

PP: 2 bits.

Payload position flag. This field indicates the position of the payload sequence in the group of payload sequences. The value "10b" means the first payload sequence of the group. "00b" indicates a packet in the middle of the group. "01b" designates the last packet. If a single payload packet forms the whole group, the value is "11b".

Group Sequence Number: 62 bits.

A sequential number of the payload group. Starts from zero and is incremented for every payload group that follows.

NTP 64-Bit Timestamp: 64 bits.

NTP 64-bit system clock timestamp of the moment when a payload has been generated meaning the payload generation has finished.

Monotonic Clock Timestamp: 64 bits.

Monotonic clock timestamp of the moment when a payload has been generated. Represents microseconds elapsed since monotonic clock epoch.

Payload Length: 32 bits.

The full length of the payload (including preceding "Payload Sequence Number" and both timestamp fields).

MD5 Checksum: 128 bits.

A hash value to confirm the payload integrity. Calculated for the whole message with the SHA-128 checksum field zeroed out.

Remaining Payload: variable length.

The remaining payload of variable length. Randomly generated sequence of bytes. MAY be generated as a sequence of 8-bit integers starting with value of the remainder after dividing the Payload Sequence Number by 32 and followed by sequentially increasing values.

For example, to emulate the "one video frame per QUIC stream" approach the payload length MUST account for the entire stream. As stream data is sent in the form of STREAM frames, the very first frame will contain Payload Sequence Number, PP flags, Group Sequence Number and the rest fields of the header, as well as some of the remaining payload data. Consequent STREAM frames will carry the rest of the payload. Both the Payload Sequence Number and the Group Sequence Number fields MUST be increased for each payload. To emulate the "one GOP per QUIC stream" approach, one QUIC stream will transport several payloads of different lengths. Both the Payload Sequence Number and the Group Sequence Number fields MUST be increased for each payload. To emulate the "video frame over QUIC datagrams" approach the payload length MUST fit in a single DATAGRAM frame. The Payload Sequence Number field MUST be increased for each sent DATAGRAM frame. A sequence of payloads SHOULD have the same Group Sequence Number, with the Payload Position Flag marking the start, the middle, and the end of the group sequence. Thus the whole group sequence marks a represent video frame.

Performance Metrics The calculation of the following metrics is suggested to be included in the scope:

• Transmission Delay (or Latency) ,
• Interarrival Jitter ,
• Time-Stamped Delay Factor (TS-DF) ,
• Total Number of Received Payloads ,
• Total Number of Missing Payloads ,
• Total Number of Reordered Payloads and Reordering Distance ,
• and others metrics as defined below.

The RECOMMENDED measurement period is 1 second, however, alternative period length is also possible. This value is dictated by the TS-DF metric specification .

Transmission Delay Transmission Delay (or Latency) is measured based on the system clock (NTP 64-Bit Timestamp ). It is RECOMMENDED to synchronize the clocks on both sender and receiver machines before an experiment so that an error associated with a clock drift is as less as possible. Transmission Delay (TD) sample is calculated at the receiver side at the moment a payload group is received by an application: where - T_NTP_RCV is the system clock time when the last payload of a group arrives at the receiver. - T_NTP_SND is the NTP 64-Bit Timestamp value extracted from the same payload. Note that TD value will be affected by the clock drift, the difference in the system time of the two clocks at the sender and at the receiver. Minimum (TD_MIN) and maximum (TD_MAX) delay estimates MUST be reset to "not available" (N/A) at the start of each measurement period, while the smoothed value (TD_SMOOTHED) MUST NOT be reset and the calculation SHOULD continue during the entire experiment. Here and throughout the current document, smoothing means applying an exponentially weighted moving average (EWMA).

Interarrival Jitter Interarrival Jitter is calculated as defined in . It is based on the concept of the Relative Transit Time between pairs of consecutive payloads received not necessarily in sequence (meaning that reordering is ignored), and is defined to be the smoothed average of the difference in payloads spacing at the receiver compared to the sender for a pair of payloads. The calculation is based on the Monotonic Clock Timestamp extracted from the payload. As jitter is calculated as an EWMA of delay variations, it MUST NOT be reset at the start of each measurement period.

Time-Stamped Delay Factor (TS-DF) Time-Stamped Delay Factor metric is calculated as defined in . The calculation of TS-DF samples is based on the Monotonic Clock Timestamp extracted from the payload. Unlike the algorithm defined in , TS-DF one does not use a smoothing factor and therefore gives a very accurate instantaneous result.

Total Number of Received Payloads A counter is initialized with zero and incremented on each payload read. The value MUST NOT be reset at the start of each measurement period.

Total Number of Received Groups A counter is initialized with zero and incremented on each payload group read. The value MUST NOT be reset at the start of each measurement period.

Total Number of Missing Payloads A counter is initialized with zero and is incremented each time a discontinuity in consecutive payloads sequence numbers (Payload Sequence Number ) is determined. Missing sequence numbers MUST be recorded. The counter is decremented by one once a payload with missing sequence number is received out of order. The value MUST NOT be reset at the start of each measurement period.

Total Number of Missing Groups The same as the Total Number of Missing Payloads, but for payload groups.

Total Number of Reordered Payloads and Reordering Distance A counter is initialized with zero and is incremented each time the Payload Sequence Number value precedes the next Expected Payload Sequence Number. The next Expected Payload Sequence Number is initialized with zero and is updated if the Payload Sequence Number value of a received payload incremented by one exceeds the current Expected Payload Sequence Number value. The value MUST NOT be reset at the start of each measurement period. TODO: Reordering Distance.

The Number of Corrupted Payloads TODO: Add description. The payload is corrupted, meaning contents were altered. This MUST NOT happen, but still MUST be checked.

The Number of Partial Payloads TODO: Add description. The payload is only partially received.

The Number of Partial Groups TODO: Add description. A group of payloads is only partially received.

The Number of Duplicated Payloads TODO: Add description.

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

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. This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK] 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] Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as "packet timestamps" for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this document includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. The European Broadcasting Union n.d. 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. Informative References Facebook Facebook Facebook Facebook RUSH is an application-level protocol for ingesting live video. This document describes the protocol and how it maps onto QUIC. 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 https://github.com/afrind/draft-rush. Twitch This document defines the core behavior for Warp, a segmented live media transport protocol. Warp maps live media to QUIC streams based on the underlying media encoding. Media is prioritized to reduce latency when encountering congestion. Haivision Network Video GmbH Haivision Network Video GmbH This document presents an approach to tunnelling SRT live streams over QUIC datagrams. QUIC [RFC9000] is a UDP-based transport protocol providing TLS encryption, stream multiplexing, and connection migration. It was designed to become a faster alternative to the TCP protocol [RFC7323]. An Unreliable Datagram Extension to QUIC [QUIC-DATAGRAM] adds support for sending and receiving unreliable datagrams over a QUIC connection, but transfers the responsibility for multiplexing different kinds of datagrams, or flows of datagrams, to an application protocol. SRT [SRTRFC] is a UDP-based transport protocol. Essentially, it can operate over any unreliable datagram transport. SRT provides loss recovery and stream multiplexing mechanisms. In its live streaming configuration SRT provides an end-to-end latency-aware mechanism for packet loss recovery. If SRT fails to recover a packet loss within a specified latency, then the packet is dropped to avoid blocking playback of further packets. The Datagram Extension to QUIC could be used as an underlying transport instead of UDP. This way QUIC would provide TLS-level security, connection migration, and potentially multi-path support. It would be easier for existing network facilities to process, route, and load balance the unified QUIC traffic. SRT on its side would provide end-to-end latency tracking and latency-aware loss recovery. Technical University Munich Technical University Munich This document specifies a minimal mapping for encapsulating RTP and RTCP packets within QUIC. It also discusses how to leverage state from the QUIC implementation in the endpoints to reduce the exchange of RTCP packets and how to implement congestion control. cisco Cisco This specification outlines the design for a media delivery protocol over QUIC. It aims at supporting multiple application classes with varying latency requirements including ultra low latency applications such as interactive communication and gaming. It is based on a publish/subscribe metaphor where entities publish and subscribe to data that is sent through, and received from, relays in the cloud. The information subscribed to is named such that this forms an overlay information centric network. The relays allow for efficient large scale deployments. Nederlandse Publieke Omroep Tencent America LLC This document describes use cases that have been discussed in the IETF community under the banner of "Media Over QUIC", provides analysis about those use cases, recommends a subset of use cases that cover live media ingest, syndication, and streaming for further exploration, and describes requirements that should guide the design of protocols to satisfy these use cases. Tsinghua University Tsinghua University Huawei Huawei Huawei This document defines Deadline-aware Transport Protocol (DTP) to provide block-based deliver-before-deadline transmission. The intention of this memo is to describe a mechanism to fulfill unreliable transmission based on QUIC as well as how to enhance timeliness of data delivery. Haivision Network Video Haivision Network Video Haivision Systems SK Telecom Co., Ltd. SK Telecom Co., Ltd. This document specifies Secure Reliable Transport (SRT) protocol. SRT is a user-level protocol over User Datagram Protocol and provides reliability and security optimized for low latency live video streaming, as well as generic bulk data transfer. For this, SRT introduces control packet extension, improved flow control, enhanced congestion control and a mechanism for data encryption. KU Leuven Facebook Protocol Labs This document describes a high-level schema for a standardized logging format called qlog. This format allows easy sharing of data and the creation of reusable visualization and debugging tools. The high-level schema in this document is intended to be protocol- agnostic. Separate documents specify how the format should be used for specific protocol data. The schema is also format-agnostic, and can be represented in for example JSON, csv or protobuf. Private Octopus Inc. The TIMESTAMP frame can be added to Quic packets when one way delay measurements are useful. The timestamp is set to the number of microseconds from the beginning of the node's epoch to the time at which the packet is sent. The draft defines the "enable_timestamp" transport parameter for negotiating the use of this extension frame, and the TIMESTAMP frame.

Acknowledgments TODO acknowledge.