Flow Metadata for Collaborative Host/Network Signaling
Internet-Draft draft-rwbr-sconepro-flow-metadata-02
Sridharan Rajagopalan
Cloud Software Group Holdings, Inc.
United States of America
sridharan.girish@gmail.com
Dan Wing
Cloud Software Group Holdings, Inc.
United States of America
danwing@gmail.com
Mohamed Boucadair
Orange
France
mohamed.boucadair@orange.com
Tirumaleswar Reddy
Nokia
India
kondtir@gmail.com
Luis Miguel Contreras Murillo
Telefonica
Spain
luismiguel.contrerasmurillo@telefonica.com
26 June 2024
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 https://danwing.github.io/metadata/draft-rwbr-flow-metadata.md.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-rwbr-sconepro-flow-metadata/.
Discussion of this document takes place on the TSV Working Group mailing list (mailto:tsvwg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tsvwg/. Subscribe at https://www.ietf.org/mailman/listinfo/tsvwg/.
Source for this draft and an issue tracker can be found at https://github.com/danwing/metadata.
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 Section 7.2 of [I-D.rwbr-tsvwg-signaling-use-cases] 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., [I-D.kaippallimalil-tsvwg-media-hdr-wireless], [I-D.reddy-tsvwg-explcit-signal]),
- IPv6 Hop-by-Hop Options (Section 4.3 of [RFC8200]),
- SCONE Protocol ([SCONEPRO]), or
- QUIC CID mapping ([I-D.wing-cidfi]).
[I-D.herbert-host2netsig] 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 (Section 3). 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 [RFC9543], and Transport domains).
The metadata is described using Concise Data Definition Language (CDDL) [CDDL] which can be expressed in both [JSON] and binary using [CBOR]. 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 Appendix A.
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" Section 10.2.
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.
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 [RFC8610] format shown in Figure 1.
CDDL Structure of the Metadata

; one or more metadata can be signaled.
metadata = {
  metadata-type: (0..1), ; 0 is Network Metadata
                         ; 1 is Application Metadata
  * $$metadata-extensions
}

; Application Metadata

$$metadata-extensions //= (
; true indicates packet of high importance
; false indicates packet of low importance
  importance: bool,
; Packets can be tagged as reliable (true) or unreliable (false)
  reliable: bool,
; Packets can be tagged as preference to keep (true) or discard (false)
  prefer-keep: bool
; Has a meaning only for packets marked as reliable
; True indicates realtime
; False indicates bulk (non-realtime)
  realtime: bool
)

; Network Metadata

; Provides information about the nominal downlink bitrate
; Returning a value set to 0 (or a very low value) should trigger
; the host to seek for better paths.

bitrate =  [+ nrlp]

nrlp =  {
  ? scope: unit,
  ? tc: uint,
  cir: uint,  ; Mbps
  cbs: uint,  ; bytes
  ? eir: uint,  ; Mbps
  ? ebs: uint,  ; bytes
  ? pir: uint,  ; Mbps
  ? pbs: uint  ; bytes
}

$$metadata-extensions //= (
   ? downlinkBitrate => 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 Figure 1 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" Section 10.2.
More details about each of these metadata are provided in Section 4 and Section 5. 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 Appendix A.
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 [RFC9293] or [QUIC]) or re-transmitted by the appplication (e.g., [RELIABLE-RTP], NTP).
- Unreliable packets are not re-transmitted by the transport (e.g., UDP, [RTP], [LOSSY-QUIC]) and also not re-transmitted by the application (e.g., [RTP]).
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 [LOSSY-QUIC], applications can send both [QUIC] reliable traffic and [LOSSY-QUIC] unreliable traffic [LOSSY-QUIC] 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:

*  "0": Subscriber
*  "1": Host
*  2-15: Unassigned values.

TC:
Specifies a traffic category to which this policy applies.
The following values are supported:

*  "0": All traffic. This is the default value.
*  "1": Streaming
*  "2": Realtime
*  "3": Bulk trafic
*  4-255: Unassigned values

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 Appendix B.
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 (Section 5.1) 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 [RFC9293] is a reliable transport protocol, while UDP [RFC0768] provides a minimal, unreliable, best-effort, message-passing transport to applications and other protocols (such as tunnels) that wish to operate over IP [RFC8085]. Protocols built over UDP may implement reliability features at the "application" layer if such a transport feature is needed [RFC8304]. For example, streams of reliable application data are sent using STREAM QUIC frames (Section 19.8 of [RFC9000]), while application data that do not require retransmission can be carried in DATAGRAM QUIC frames [RFC9221]. 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 [RFC7198], [RFC7197], or [RFC7104].
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 [RFC8911]. 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 Table 1.
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 (Section 4.9 of [RFC8126]).
Values in the 100-149 range can be assigned using "Expert Review" policy (Section 4.5 of [RFC8126]).
Values in the 150-249 range can be assigned using "First Come First Served" (Section 4.4 of [RFC8126]). 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
[CDDL]

Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures
H. Birkholz
C. Vigano
C. Bormann
June 2019
RFC 8610
DOI 10.17487/RFC8610
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[RFC8610]

Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures
H. Birkholz
C. Vigano
C. Bormann
June 2019
RFC 8610
DOI 10.17487/RFC8610
[RFC8126]

Guidelines for Writing an IANA Considerations Section in RFCs
M. Cotton
B. Leiba
T. Narten
June 2017
BCP 26
RFC 8126
DOI 10.17487/RFC8126
Informative References
[QUIC]

QUIC: A UDP-Based Multiplexed and Secure Transport
J. Iyengar, Ed.
M. Thomson, Ed.
May 2021
RFC 9000
DOI 10.17487/RFC9000
[LOSSY-QUIC]

An Unreliable Datagram Extension to QUIC
T. Pauly
E. Kinnear
D. Schinazi
March 2022
RFC 9221
DOI 10.17487/RFC9221
[RTP]

RTP: A Transport Protocol for Real-Time Applications
H. Schulzrinne
S. Casner
R. Frederick
V. Jacobson
July 2003
STD 64
RFC 3550
DOI 10.17487/RFC3550
[RELIABLE-RTP]

RTP Retransmission Payload Format
J. Rey
D. Leon
A. Miyazaki
V. Varsa
R. Hakenberg
July 2006
RFC 4588
DOI 10.17487/RFC4588
[SCONEPRO]

SCONEPRO Working Group Charter
02 February 2024
[I-D.rwbr-tsvwg-signaling-use-cases]

Host to Network Signaling Use Cases for Collaborative Traffic Differentiation
Sridharan Rajagopalan
Cloud Software Group Holdings, Inc.
Dan Wing
Cloud Software Group Holdings, Inc.
Mohamed Boucadair
Orange
Tirumaleswar Reddy.K
Nokia
17 March 2024
Internet-Draft draft-rwbr-tsvwg-signaling-use-cases-02
[I-D.kaippallimalil-tsvwg-media-hdr-wireless]

Media Handling Considerations for Wireless Networks
John Kaippallimalil
Futurewei
Sri Gundavelli
Cisco
Spencer Dawkins
Tencent America LLC
14 February 2024
Internet-Draft draft-kaippallimalil-tsvwg-media-hdr-wireless-04
[I-D.reddy-tsvwg-explcit-signal]

An Approach for Encrypted Transport Protocol Path Explicit Signals
Tirumaleswar Reddy.K
Nokia
Dan Wing
Citrix Systems, Inc.
Mohamed Boucadair
Orange
7 July 2023
Internet-Draft draft-reddy-tsvwg-explcit-signal-01
[RFC8200]

Internet Protocol, Version 6 (IPv6) Specification
S. Deering
R. Hinden
July 2017
STD 86
RFC 8200
DOI 10.17487/RFC8200
[I-D.wing-cidfi]

Framework for CID Flow Indicator (CIDFI)
Dan Wing
Cloud Software Group Holdings, Inc.
Tirumaleswar Reddy.K
Nokia
Mohamed Boucadair
Orange
14 December 2023
Internet-Draft draft-wing-cidfi-04
[I-D.herbert-host2netsig]

Host to Network Signaling
Tom Herbert
SiPanda
4 October 2023
Internet-Draft draft-herbert-host2netsig-00
[RFC9543]

A Framework for Network Slices in Networks Built from IETF Technologies
A. Farrel, Ed.
J. Drake, Ed.
R. Rokui
S. Homma
K. Makhijani
L. Contreras
J. Tantsura
March 2024
RFC 9543
DOI 10.17487/RFC9543
[JSON]

The JavaScript Object Notation (JSON) Data Interchange Format
T. Bray, Ed.
December 2017
STD 90
RFC 8259
DOI 10.17487/RFC8259
[CBOR]

Concise Binary Object Representation (CBOR)
C. Bormann
P. Hoffman
December 2020
STD 94
RFC 8949
DOI 10.17487/RFC8949
[RFC9293]

Transmission Control Protocol (TCP)
W. Eddy, Ed.
August 2022
STD 7
RFC 9293
DOI 10.17487/RFC9293
[RFC0768]

User Datagram Protocol
J. Postel
August 1980
STD 6
RFC 768
DOI 10.17487/RFC0768
[RFC8085]

UDP Usage Guidelines
L. Eggert
G. Fairhurst
G. Shepherd
March 2017
BCP 145
RFC 8085
DOI 10.17487/RFC8085
[RFC8304]

Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)
G. Fairhurst
T. Jones
February 2018
RFC 8304
DOI 10.17487/RFC8304
[RFC9000]

QUIC: A UDP-Based Multiplexed and Secure Transport
J. Iyengar, Ed.
M. Thomson, Ed.
May 2021
RFC 9000
DOI 10.17487/RFC9000
[RFC9221]

An Unreliable Datagram Extension to QUIC
T. Pauly
E. Kinnear
D. Schinazi
March 2022
RFC 9221
DOI 10.17487/RFC9221
[RFC7198]

Duplicating RTP Streams
A. Begen
C. Perkins
April 2014
RFC 7198
DOI 10.17487/RFC7198
[RFC7197]

Duplication Delay Attribute in the Session Description Protocol
A. Begen
Y. Cai
H. Ou
April 2014
RFC 7197
DOI 10.17487/RFC7197
[RFC7104]

Duplication Grouping Semantics in the Session Description Protocol
A. Begen
Y. Cai
H. Ou
January 2014
RFC 7104
DOI 10.17487/RFC7104
[RFC8911]

Registry for Performance Metrics
M. Bagnulo
B. Claise
P. Eardley
A. Morton
A. Akhter
November 2021
RFC 8911
DOI 10.17487/RFC8911
[I-D.kwbdgrr-tsvwg-net-collab-rqmts]

Requirements for Network Collaboration Signaling
John Kaippallimalil
Futurewei
Dan Wing
Cloud Software Group Holdings, Inc.
Sri Gundavelli
Cisco
Sridharan Rajagopalan
Cloud Software Group Holdings, Inc.
Spencer Dawkins
Tencent America LLC
Mohamed Boucadair
Orange
Tirumaleswar Reddy.K
Nokia
7 June 2024
Internet-Draft draft-kwbdgrr-tsvwg-net-collab-rqmts-01
Examples of Host-to-Network Metadata Encoding
Video Streaming
Video Streaming Metadata:
The use case requirements for Table 2 is explained in detail in [I-D.kwbdgrr-tsvwg-net-collab-rqmts]. 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:

metadata = {
  "metadata-type": 1,
  "Application Metadata": {
    "importance": false,
    "reliable": true,
    "realtime": true
  }
}

Audio:

metadata = {
  "metadata-type": 1,
  "Application Metadata": {
    "importance": true,
    "reliable": true,
    "realtime": true
  }
}

Video delta P-frame:

metadata = {
  "metadata-type": 1,
  "Application Metadata": {
    "importance": false,
    "reliable": false,
    "prefer-keep": false
  }
}

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:

metadata = {
  "metadata-type": 1,
  "Application Metadata": {
    "importance": false,
    "reliable": true,
    "realtime": true
  }
}

Video delta frame:

metadata = {
  "metadata-type": 1,
  "Application Metadata": {
    "importance": false,
    "reliable": false,
    "prefer-keep": false
  }
}

Audio:

metadata = {
  "metadata-type": 1,
  "Application Metadata": {
    "importance": true,
    "reliable": true,
    "realtime": true
  }
}

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 [I-D.kwbdgrr-tsvwg-net-collab-rqmts]. 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:

metadata = {
  "metadata-type": 1,
  "Application Metadata": {
    "importance": true,
    "reliable": true,
    "realtime": true
  }
}

Glyph smoothing:

metadata = {
  "metadata-type": 1,
  "Application Metadata": {
    "importance": false,
    "reliable": false,
    "prefer-keep": false
  }
}

Interactive Audio:

metadata = {
  "metadata-type": 1,
  "Application Metadata": {
    "importance": true,
    "reliable": false,
    "prefer-keep": true
  }
}

Haptic feedback:

metadata = {
  "metadata-type": 1,
  "Application Metadata": {
    "importance": true,
    "reliable": false,
    "prefer-keep": false
  }
}

File copy:

metadata = {
  "metadata-type": 1,
  "Application Metadata": {
    "importance": false,
    "reliable": true,
    "realtime": false
  }
}

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 Figure 2 indicates a CIR (1 Mbps) for the requesting user:
Example of Network-to-Host Metadata for Video Streaming

{
  "downlinkBitrate": {
    "cir": 1
  }
}