]> Cloud Software Group Holdings, Inc.

United States of America sridharan.girish@gmail.com

Cloud Software Group Holdings, Inc.

United States of America danwing@gmail.com

Orange

France mohamed.boucadair@orange.com

Nokia

India kondtir@gmail.com

Telefonica

Spain luismiguel.contrerasmurillo@telefonica.com

Network Network Working Group user experience bandwidth priority enriched feedback media streaming realtime media QoS 5G Wi-Fi WiFi DTLS Connection Identifier DTLS-SRTP QUIC Connection Identifier QUIC This document defines per-flow and per-packet metadata for both network-to-host and host-to-network signaling in Concise Data Definition Language (CDDL) which expresses both CBOR and JSON. The common metadata definition allows interworking between signaling protocols with high fidelity. The metadata is also self- describing to improve interpretation by network elements and endpoints while reducing the need for version negotiation. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the TSV Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Historically, metadata is defined within each protocol. While this can be very efficient on the wire (e.g., DSCP consumes only 6 bits) it suffers from inability to authorize or authenticate the metadata signaling. But the more significant problem is inability to interwork between signaling protocols because each have different definitions. Such interworking is often needed when the metadata signaling protocol for packets leaving a network differs from the metadata signaling protocol entering a different network. For example, important packets leaving a server and its network might be marked with DSCP (as the sending host is known and trusted) but the receiving network doesn't trust the DSCP bits in received packets because there is no authorization or authentication for differential treatment. This document does not assume nor require that all on-path network elements must understand the meaning associated with signaled metadata. Only a few network nodes would need to be upgraded to support the metadata signaling. By using the same metadata, both networks can communicate how packets should be treated and use their own signaling mechanism with their network elements (e.g., routers or proxies). Readers should refer to for a discussion about why application- and protocol-specific signaling channels are Both the above use cases are improved by metadata described in this document. This document is a companion to host-to-network signaling the metadata itself, such as:

• UDP Options (e.g., , ),
• IPv6 Hop-by-Hop Options (),
• SCONE Protocol (), or
• QUIC CID mapping ().

provides an analysis of most of those metadata signaling mechanisms. This document does not assume nor preclude any companion signaling protocol. Also, the document does not preclude API-based approaches to control flows, packets, applications, etc. that are bound to a given metadata and which will benefit from the differentiated behavior. As such, the metadata in this document is defined to be independent of the signaling protocol (). In doing so, we ensure that consistent metadata definitions are used by the various signaling protocols. Also, this approach allows to factorize key considerations such as security and operational considerations. This approach also ease passing policies between controllers of domains involved in packet delivery (e.g., RAN, Core, network slicing , and Transport domains). The metadata is described using Concise Data Definition Language (CDDL) which can be expressed in both and binary using . Both the JSON and CBOR encodings are self-describing. It is out of scope of this document to define how the proposed encoding will be mapped to a specific signaling protocol. If the companion signaling protocol supports host-to-network metadata, individual packets within a flow can contain metadata describing their drop preference or their reliability. The network elements aware of this metadata can apply preferential or differential treatment to those packets, within the same flow, during a 'reactive traffic policy' event. It is also assumed that such network elements are provisioned with local policy that guides their behavior jointly with a signaled metadata. Examples of metadata signaling for video streaming and for remote desktop are provided in . For network-to-host metadata, a host can be informed of network policy for nominal downlink bandwidth. Certain applications, such as most especially video streaming applications, can use that information to optimize their video streaming bandwidth to fit within that policy. To track metadata that are defined for host/network signalling, a new IANA registry is defined: "Flow Metadata Registry" .

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. This document uses the following terms:

Reactive policy:

Treatment given to a flow when an exceptional event occurs, such as diminished throughput to the host caused by radio interference or weak radio signal, congestion on the network caused by other users or other applications on the same host, denial of service attacks, etc. Characterizing such exceptional events is deployment-specific.

Intentional policy:

Configured bandwidth, pps, or similar throughput constraints applied to a flow, application, host, or subscriber.

Metadata Structure The metadata is described in CDDL format shown in .

CDDL Structure of the Metadata nrlp, ; Indicates whether a flow is to be offloaded to alternate ; available paths. pref-alt-path: bool ) downlinkBitrate = "downlinkBitrate" burst-d = "burst-info" ]]>

The structure shown in does not assume that the metadata will be encoded as a single blob when mapped to a signaling protocol or that all the metadata components will be mapped. Such matters are specific to the individual signaling protocols and deployment contexts. New metadata for collaborative host/network signaling MUST be registered in the IANA registry, "Flow Metadata Registry" . More details about each of these metadata are provided in and . Both client and network intended behaviors are specified for each metadata.

Host-to-Network Metadata Metadata is characterized into two different nature:

Network Metadata:

This consists of metadata that specifies how a network element should treat that packet. The network metadata comprises of the importance metadata. This field indicates whether a packet is more important or less important.

Application Metadata:

This consists of metadata that specifies how the application treats that packet. The appplication metadata comprises of two components: Keep/Discard and Reliable/Unreliable.

Packet Importance ('Importance') The "Importance" metadata signifies if the packet is of more important (true) or less important (false) by the host, relative to other packets in the same flow. Importance belongs to Network Metadata. An application would mark a packet as important when it needs the network to treat the packet with greater preference compared to the unmarked packets or to packets marked important=false (of the same flow). This tagging does not provide more privileges to an application with regards to resources usage compared to the absence of signal. An example of this interpretation is specified in .

Network Treatment During a reactive policy event, a network element is encouraged to discard packets marked importance=false in favor of packets marked importance=true, for the same flow.

Packet Type - Reliable/Unreliable ('PacketType') The "Reliable" metadata indicates if a packet is reliably transmitted by the host.

• Reliable packets are re-transmitted by the underlying transport (e.g., TCP or ) or re-transmitted by the appplication (e.g., , NTP).
• Unreliable packets are not re-transmitted by the transport (e.g., UDP, , ) and also not re-transmitted by the application (e.g., ).

Packets marked reliable, if delayed excessively or dropped outright, will be re-transmitted (up to a maximum retries) by the sender application, appearing on the network again. Thus, delaying or discarding such packets does not reduce the amount of transmitted data in a network; it only defers when it appears on the network. Reliable/Unreliable belongs to Application Metadata.

Network Treatment During a reactive policy event, dropping unreliable traffic is preferred over dropping reliable traffic. The reliable traffic will be re-transmitted by the sender so dropping such traffic only defers it until later, but this deferral can be useful.

Packet Nature ('PacketNature') This metadata indicates discard preference for unreliable traffic and reliable traffic, as detailed below.

Unreliable Traffic Packets are marked with 'prefer-keep' set to either true or false. When set to true, it indicates a preference to keep the packet. Conversely, when set to false, it signals that the packet may be subject to discard based on a reactive policy. Many flows contain a mix of important packets and less-important packets, but applications seldom signal that difference themselves let alone signal the difference to the network. Rather, applications send everything over a reliable transport (TCP or QUIC) and leave it at that, as evidenced by video streaming using TCP. With the advent of , applications can send both reliable traffic and unreliable traffic on the same 5-tuple. With host-to-network metadata signaling, the network can become an active assistant in such flows during a reactive policy event by endeavouring to send the more-important 'prefer-keep' traffic at the expense of the less-important 'may-discard' traffic. The reason why an application transmits a packet marked as 'prefer-keep' set to false, when the application has the capability to avoid sending that packet, is application-specific.

Network Treatment During a reactive policy event, dropping packets with 'prefer-keep' set to false is preferred over dropping 'prefer-keep' set to true packets. Absent such discard preference indication, the network element will blindly drop packets during a reactive policy event.

Reliable Traffic For reliable traffic, "realtime" metadata indicates whether the packet belongs to bulk or real-time traffic. An application such as a web browser might mark certain flows as realtime (e.g., the flow is related to dynamically updating a search box and quick responses help the user experience) and other flows as bulk (e.g., file download, file upload).

Network Treatment Realtime traffic prefers lower latency network paths and bulk traffic prefers high throughoupt paths.

Network to Host Metadata

Downlink Bitrate ('DownlinkBitrate') Monthly data quotas on cellular networks can be easily exceeded by video streaming, in particular, if the client chooses excessively high quality or routinely abandons watching videos that were downloaded. The network can assist the client by informing the client of the network's bandwidth policy. If the video is encoded with variable bitrate, the bitrate cannot exceed the indicated bitrate.

Scope:

Specifies whether the policy is per host, per subscriber, etc.

The following values are supported:

TC:

Specifies a traffic category to which this policy applies.

The following values are supported:

Committed Information Rate (CIR) (Mbps):

Specifies the maximum number of bits that a network can send during one second over an attachment circuit for a traffic category.

This parameter is mandatory.

Committed Burst Size (CBS) (bytes):

Specifies the maximum burst size that can be transmitted at CIR.

MUST be greated than zero.

This parameter is mandatory.

Excess Information Rate (EIR) (Mbps):

Specifies the maximum number of bits that a network can send during one second for a traffic category that is out of profile.

This parameter is optional.

Excess Burst Size (EBS) (bytes):

Indicates that maximum excess burst size that is allowed while not complying with the CIR.

MUST be greater than zero, if present.

This parameter is optional.

Peak Information Rate (PIR) (Mbps):

Traffic that exceeds the CIR and the CBS is metered to the PIR.

This parameter is optional.

Peak Burst Size (PBS) (bytes):

Specifies the maximum burst size that can be transmitted at PIR.

MUST be greater than zero, if present.

Units Bitrates are expressed in Mbps and burst in bytes.

Host Treatment The host chooses a video streaming bitrate at or below the signaled rate. The host may also choose to signal the received bitrate to the remote peer. The remote peer will adapt its transmission behavior to comply with the received bitrate. An example of the encoding is provided in .

Prefer Alternate Path ('pref-alt-path') There are also crisis cases where nominal network resources cannot be used at maximum to handle packets. A network would thus seek to offload some of the traffic during these events. Under such exceptional events, a network element may signal to a host that it is preferrable to use alternate paths, if available. An alternate path is typically an alternate network attachment. After the crisis has subsided, the network should signal with pref-alt-path=false. The 'pref-alt-path' metadata may be sent together with the bitrate metadata () set to a very low value.

Host Treatment The host offloads its connections to alternate available paths.

Guidance For Mapping Metadata to Specific Signaling Protocols TBC.

Implementation Impact of Metadata

Reliable/Unreliable set by the respective transport level protocol TCP is a reliable transport protocol, while UDP provides a minimal, unreliable, best-effort, message-passing transport to applications and other protocols (such as tunnels) that wish to operate over IP . Protocols built over UDP may implement reliability features at the "application" layer if such a transport feature is needed . For example, streams of reliable application data are sent using STREAM QUIC frames (), while application data that do not require retransmission can be carried in DATAGRAM QUIC frames . Applications that are utilizing such a protocol, will have to choose the delivery service (reliable or loss-tolerant) based upon the nature of the packet being sent -- loss-tolerant packet cannot be carried in a reliable frame and vice-versa. Hence, based on the transport service being invoked, setting of the reliable/unreliable metadata entry can be offloaded to the underlying transport protocol, unless specifically overridden by the application.

Offloading Loss-Avoidance to the network Network nodes, upon learning of the nature of a packet (reliable/prefer-keep) can choose to implement loss avoidance algorithms between hops where there is packet loss detected (e.g., using out-of-band or in-band QoS measurement, which is out of the scope of this document). By doing so, end-to-end retransmissions can be reduced/avoided thereby minimizing the need for handling loss at the application layer using protocols such as , , or .

Manageability Considerations

Impact on Network Operation TBC.

Security Considerations Metadata increases the information available to attackers to distinguish important packets from less-important packets, which the attacker might use to attack such packets (e.g., prevent their delivery) or attempt to decrypt those packets. It is RECOMMENDED to encrypt or obfuscate the metadata information so it is only available to hosts and to authorized network elements, while maintaining minimal resource consumption. The method of encryption or obfuscation is not described in this document but rather in other documents describing how this metadata is encoded and exchanged amongst hosts and network elements.

IANA Considerations

Metadata for Collaborative Host/Network Signaling Registry Group This document requests IANA to create a new registry group, entitled "Metadata for Collaborative Host/Network Signaling".

Flow Metadata Registry IANA is requested to create a new registry, entitled "Flow Metadata Registry", under the "Metadata for Collaborative Host/Network Signaling" registry group. This registry is inspired by the "Performance Metrics Registry" created by . The structure of the registry is as follows:

Identifier:

A numeric identifier for the registered metadata.

The Identifier 0 is Reserved.

The Identifier values from 250 to 255 are reserved for private or experimental use.

Name:

Name of the registered metadata.

Description:

Provides a description of the intended use of the registered metadata.

Reference:

Lists the authoritative reference that specifies the registered metadata.

Version:

Tracks the current version of the metadata.

The initial version of a new registered metadata MUST be 1.0.

IANA will bump the version when a new RFC that changes the format/semantic of a registered entry.

The initial values of the registry are listed in . Initial Values

Identifier	Name	Description	Reference	Version
0		Reserved	This-Document
1	Importance	Indicates the level of importance of a packet in a flow	This-Document	1.0
2	PacketType	Indicates whether a packet is reliably or unreliably transmitted	This-Document	1.0
3	PacketNature	Indicates a discard preference	This-Document	1.0
4	DownlinkBitrate	Specifies the maximum downlink bitrate	This-Document	1.0
5	PreferAltPath	Sollicits the hosts to use an alternate path if available	This-Document	1.0
250-255	Exp	Reserved for private use	This-Document	1.0

New values in the 6-99 range can be assigned using "Standards Action" policy (). Values in the 100-149 range can be assigned using "Expert Review" policy (). Values in the 150-249 range can be assigned using "First Come First Served" (). This range can be, e.g., used by other SDOs to register metadata that are specific to their domain and which is not used outside that scope.

References Normative References This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. 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 proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References 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. 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] RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo. [STANDARDS-TRACK] Cloud Software Group Holdings, Inc. Cloud Software Group Holdings, Inc. Orange Nokia Host-to-network (and vice versa) signaling can improve the user experience by informing the network which flows are more important and which packets within a flow are more important without having to disclose the content of the packets being delivered. The differentiated service may be provided at the network (e.g., packet discard preference), the sender (e.g., adaptive transmission or session migration), or through cooperation of both the host and the network. This document lists use cases demonstrating the need for a mechanism to share metadata about flows between a receiving host and its networks to enable differentiated traffic treatment for packets sent to the host. Such a mechanism is typically implemented using a signaling protocol between the host and a set of network elements. Futurewei Cisco Tencent America LLC Wireless networks like 5G cellular or Wi-Fi experience significant variations in link capacity over short intervals due to wireless channel conditions, interference, or the end-user's movement. These variations in capacity take place in the order of hundreds of milliseconds and is much too fast for end-to-end congestion signaling by itself to convey the changes for an application to adapt. Media applications on the other hand demand both high throughput and low latency, and may adjust the size and quality of a stream to network bandwidth available or dynamic change in content coded. However, catering to such media flows over a radio link with rapid changes in capacity requires the buffers and congestion to be managed carefully. Wireless networks need additional information to manage radio resources optimally to maximize network utilization and application performance. This draft provides requirements on metadata about the media transported, its scalability, privacy, and other related considerations. Nokia Citrix Systems, Inc. Orange This document defines a mechanism for endpoints to explicitly signal encrypted metadata to the network, and the network to signal its ability to accommodate that metadata back to the endpoints. This mechanism can be used where the endpoints desire that some network elements along the path receive these explicit signals. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. Cloud Software Group Holdings, Inc. Nokia Orange Host-to-network signaling and network-to-host signaling can improve the user experience to adapt to network's constraints and share expected application needs, and thus to provide differentiated service to a flow and to packets within a flow. The differentiated service may be provided at the network (e.g., packet prioritization), the server (e.g., adaptive transmission), or both. This document describes how clients can communicate with their nearby network elements so they can learn network constraints. Optionally, with QUIC server support their incoming QUIC packets can be mapped to metadata about their contents so packet importance can influence both intentional and reactive management policies. The framework handles both directions of a flow. SiPanda This document discusses the motivations, use cases, and requirements for Host to Network Signaling. In Host to Network Signaling, hosts annotate packets with information that is intended for consumption by on-path elements. Signals may be used to request services on a per packet basis from on-path elements, to request admission into the network, or to provide diagnostics and tracing information. This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context. The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security. This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage. This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. RFC 8303 documents the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite, and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services. This document provides input to and context for that document, as well as offers a road map to documentation that may help users of the UDP and UDP-Lite protocols. 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. Packet loss is undesirable for real-time multimedia sessions but can occur due to a variety of reasons including unplanned network outages. In unicast transmissions, recovering from such an outage can be difficult depending on the outage duration, due to the potentially large number of missing packets. In multicast transmissions, recovery is even more challenging as many receivers could be impacted by the outage. For this challenge, one solution that does not incur unbounded delay is to duplicate the packets and send them in separate redundant streams, provided that the underlying network satisfies certain requirements. This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules. A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as "time-shifted redundancy", "temporal redundancy", or simply "delayed duplication". This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol. Packet loss is undesirable for real-time multimedia sessions, but it can occur due to congestion or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework. Grouping semantics at the Synchronization Source (SSRC) level are also defined in this document for RTP streams using SSRC multiplexing. This document defines the format for the IANA Registry of Performance Metrics. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers. Futurewei Cloud Software Group Holdings, Inc. Cisco Cloud Software Group Holdings, Inc. Tencent America LLC Orange Nokia Wireless networks (e.g., cellular or WLAN) experience significant but transient variations in link quality and have policy constraints (e.g., bandwidth) that affect user experience. Collaborative signaling (e.g., host-to-network and server-to-network) can improve the user experience by informing the network about the nature and relative importance of packets (frames, streams, etc.) without having to disclose the content of the packets. Moreover, the collaborative signalling may be enabled so that hosts are aware of the network's treatment of incoming packets. Also, host-to-network collaboration can be put in place without revealing the identity of the remote servers. This collaboration allows for differentiated services at the network (e.g., packet discard preference), the sender (e.g., adaptive transmission), or through cooperation of server / host and the network. This document lists some use cases that illustrate the need for a mechanism to share metadata and outlines requirements for both host- to-network (and vice versa) and server-to-network (and vice versa). The document focuses on intra-flow or flows bound to the same user.

Examples of Host-to-Network Metadata Encoding

Video Streaming Video Streaming Metadata: The use case requirements for is explained in detail in . The audio is more important than video (importance=high, PT=keep, RU=reliable), video key frames have middle importance (importance=low, PT=discard, RU=reliable), and both types of video delta frames (P-frame and B-frame) have least importance (importance=low, PT=discard, RU=unreliable). The metadata for the use case is defined as follows: Example Values for Video Streaming Metadata

Traffic type	Importance	PacketNature	PacketType
video I-frame (key frame)	low	realtime	reliable
video delta P-frame	low	discard	unreliable
video delta B-frame	low	discard	unreliable
audio	high	realtime	reliable

The encoding of the metadata in CDDL for the traffic will look like: Video I-frame: Audio: Video delta P-frame:

Interactive Media Based on metadata types listed in this document, the host to network metadata parameters for interactive media type is given below. Interactive A/V, downstream Metadata: Example Values for Interactive A/V, downstream

Traffic type	Importance	PacketNature	PacketType
video key frame	low	realtime	reliable
video delta frame	low	discard	unreliable
audio	high	realtime	reliable

Example Values for Interactive A/V, upstream

Traffic type	Importance	PacketNature	PacketType
video key frame	low	realtime	reliable
video delta frame	low	discard	unreliable
audio	high	realtime	reliable

Many interactive audio/video applications also support sharing the presenter's screen, file, video, or pictures. During this sharing the presenter's video is less important but the screen or picture is more important. This change of imporance can be conveyed in metadata to the network, as in the table below: Interactive A/V, upstream Metadata: Example Values for Interactive A/V with picture sharing, upstream

Traffic type	Importance	PacketNature	PacketType
video key frame	low	realtime	reliable
video delta frame	low	discard	unreliable
audio	high	realtime	reliable
picture sharing	high	realtime	reliable

In many scenarios a game or VoIP application will want to signal different metadata for the same type of packet in each direction. For example, for a game, video in the server-to-client direction might be more important than audio, whereas input devices (e.g., keystrokes) might be more important than audio.

• Todo: finish the encoding section for more metadata represented above.

Encoding: Video key frame: Video delta frame: Audio:

Live Streaming Based on metadata types listed in this document, the host to network metadata parameters for interactive media type is given below. Metadata for live-streaming that prefers video over audio: (eg. Superbowl game coverage) Example Values for live streaming of video preferred event

Traffic type	Importance	PacketNature	PacketType
video key frame	high	realtime	reliable
video delta frame	low	discard	unreliable
audio	low	discard	unreliable

Metadata for live-streaming that prefers audio over video: (eg. Music Concert) Example Values for live streaming of audio preferred event

Traffic type	Importance	PacketNature	PacketType
video key frame	low	realtime	reliable
video delta frame	low	discard	unreliable
audio	high	realtime	reliable

Remote Desktop Virtualization Example packet metadata for Desktop Virtualization (like Citrix Virtual Apps and Desktops - CVAD) application. Remote Desktop Virtualization Metadata: The use case requirements for the below table is explained in detail in . The metadata for the use case is defined as follows: Example Values for Remote Desktop Virtualization Metadata, server to client

Traffic type	Importance	PacketNature	PacketType	Comments
Glyph critical	high	realtime	reliable	The frames that form the base for the image is more critical and needs to be transmitted as reliably as possible. Retransmits of these are harmful to the UX.**
Interactive (or streaming) audio	high	keep	unreliable
Haptic feedback	high	discard	unreliable	Virtualizing haptic feedback is real-time and high importance although the feedback being delivered late is of no use. So dropping the packet altogether and not retransmitting it makes more sense
Interactive (or streaming) video key frame	low	keep	unreliable	Video key frames form the base frames of a video upon which the next 'n' timeframe of video updates is applied on. These frames, are hence, critical and without them, the video would not be coherent until the next critical frame is received. Retransmits of these are harmful to the UX. ***
File copy	low	bulk	reliable
Interactive (or streaming) video predictive frame	low	discard	unreliable	Video predictive frames can be lost, which would result in minor glitch but not compromise the user activity and video would still be coherent and useful. The reception of subsequent video key frame would mitigate the loss in quality caused by lost predictive frames.
Glyph smoothing	low	discard	Unreliable	The smoothing elements of the glyph can be lost and would still present a recognizable image, although with a lesser quality. Hence, these can be marked as loss tolerant as the user action is still completed with a small compromise to the UX. Moreover, with the reception of the next glyph critical frame would mitigate the loss in quality caused by lost glyph smoothing elements.

Encoding: Glyph critical: Glyph smoothing: Interactive Audio: Haptic feedback: File copy:

Example of Network-to-Host Metadata for Video Streaming A network element can signal the maximum bandwidth allowed for video streaming. Typically, this policy limit exists in cellular networks. The example shown in indicates a CIR (1 Mbps) for the requesting user:

Example of Network-to-Host Metadata for Video Streaming