Skip to main content

Flow Metadata for Collaborative Host/Network Signaling
draft-rwbr-sconepro-flow-metadata-02

Document Type Active Internet-Draft (individual)
Authors Sridharan Rajagopalan , Dan Wing , Mohamed Boucadair , Tirumaleswar Reddy.K , Luis M. Contreras
Last updated 2024-06-26
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-rwbr-sconepro-flow-metadata-02
Network Working Group                                     S. Rajagopalan
Internet-Draft                                                   D. Wing
Intended status: Standards Track                    Cloud Software Group
Expires: 28 December 2024                                   M. Boucadair
                                                                  Orange
                                                                T. Reddy
                                                                   Nokia
                                                        L. M. C. Murillo
                                                              Telefonica
                                                            26 June 2024

         Flow Metadata for Collaborative Host/Network Signaling
                  draft-rwbr-sconepro-flow-metadata-02

Abstract

   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

   This note is to be removed before publishing as an RFC.

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Rajagopalan, et al.     Expires 28 December 2024                [Page 1]
Internet-Draft                Flow Metadata                    June 2024

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 28 December 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   3.  Metadata Structure  . . . . . . . . . . . . . . . . . . . . .   5
   4.  Host-to-Network Metadata  . . . . . . . . . . . . . . . . . .   7
     4.1.  Packet Importance ('Importance')  . . . . . . . . . . . .   7
       4.1.1.  Network Treatment . . . . . . . . . . . . . . . . . .   7
     4.2.  Packet Type - Reliable/Unreliable ('PacketType')  . . . .   7
       4.2.1.  Network Treatment . . . . . . . . . . . . . . . . . .   8
     4.3.  Packet Nature ('PacketNature')  . . . . . . . . . . . . .   8
       4.3.1.  Unreliable Traffic  . . . . . . . . . . . . . . . . .   8
         4.3.1.1.  Network Treatment . . . . . . . . . . . . . . . .   9
       4.3.2.  Reliable Traffic  . . . . . . . . . . . . . . . . . .   9
         4.3.2.1.  Network Treatment . . . . . . . . . . . . . . . .   9
   5.  Network to Host Metadata  . . . . . . . . . . . . . . . . . .   9
     5.1.  Downlink Bitrate ('DownlinkBitrate')  . . . . . . . . . .   9
       5.1.1.  Units . . . . . . . . . . . . . . . . . . . . . . . .  11
       5.1.2.  Host Treatment  . . . . . . . . . . . . . . . . . . .  11
     5.2.  Prefer Alternate Path ('pref-alt-path') . . . . . . . . .  11
       5.2.1.  Host Treatment  . . . . . . . . . . . . . . . . . . .  11

Rajagopalan, et al.     Expires 28 December 2024                [Page 2]
Internet-Draft                Flow Metadata                    June 2024

   6.  Guidance For Mapping Metadata to Specific Signaling
           Protocols . . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  Implementation Impact of Metadata . . . . . . . . . . . . . .  11
     7.1.  Reliable/Unreliable set by the respective transport level
           protocol  . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.2.  Offloading Loss-Avoidance to the network  . . . . . . . .  12
   8.  Manageability Considerations  . . . . . . . . . . . . . . . .  12
     8.1.  Impact on Network Operation . . . . . . . . . . . . . . .  12
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  Metadata for Collaborative Host/Network Signaling Registry
            Group  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.2.  Flow Metadata Registry . . . . . . . . . . . . . . . . .  13
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Appendix A.  Examples of Host-to-Network Metadata Encoding  . . .  18
     A.1.  Video Streaming . . . . . . . . . . . . . . . . . . . . .  18
     A.2.  Interactive Media . . . . . . . . . . . . . . . . . . . .  20
     A.3.  Live Streaming  . . . . . . . . . . . . . . . . . . . . .  22
     A.4.  Remote Desktop Virtualization . . . . . . . . . . . . . .  23
   Appendix B.  Example of Network-to-Host Metadata for Video
           Streaming . . . . . . . . . . . . . . . . . . . . . . . .  26
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

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

Rajagopalan, et al.     Expires 28 December 2024                [Page 3]
Internet-Draft                Flow Metadata                    June 2024

   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

Rajagopalan, et al.     Expires 28 December 2024                [Page 4]
Internet-Draft                Flow Metadata                    June 2024

   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.

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.

3.  Metadata Structure

   The metadata is described in CDDL [RFC8610] format shown in Figure 1.

   ; 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

Rajagopalan, et al.     Expires 28 December 2024                [Page 5]
Internet-Draft                Flow Metadata                    June 2024

   ; 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"

                  Figure 1: CDDL Structure of the Metadata

   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.

Rajagopalan, et al.     Expires 28 December 2024                [Page 6]
Internet-Draft                Flow Metadata                    June 2024

   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.

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

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

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

4.2.  Packet Type - Reliable/Unreliable ('PacketType')

   The "Reliable" metadata indicates if a packet is reliably transmitted
   by the host.

Rajagopalan, et al.     Expires 28 December 2024                [Page 7]
Internet-Draft                Flow Metadata                    June 2024

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

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

4.3.  Packet Nature ('PacketNature')

   This metadata indicates discard preference for unreliable traffic and
   reliable traffic, as detailed below.

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

Rajagopalan, et al.     Expires 28 December 2024                [Page 8]
Internet-Draft                Flow Metadata                    June 2024

   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.

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

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

4.3.2.1.  Network Treatment

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

5.  Network to Host Metadata

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

Rajagopalan, et al.     Expires 28 December 2024                [Page 9]
Internet-Draft                Flow Metadata                    June 2024

   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.

Rajagopalan, et al.     Expires 28 December 2024               [Page 10]
Internet-Draft                Flow Metadata                    June 2024

5.1.1.  Units

   Bitrates are expressed in Mbps and burst in bytes.

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

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

5.2.1.  Host Treatment

   The host offloads its connections to alternate available paths.

6.  Guidance For Mapping Metadata to Specific Signaling Protocols

   TBC.

7.  Implementation Impact of Metadata

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

Rajagopalan, et al.     Expires 28 December 2024               [Page 11]
Internet-Draft                Flow Metadata                    June 2024

   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.

7.2.  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].

8.  Manageability Considerations

8.1.  Impact on Network Operation

   TBC.

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

10.  IANA Considerations

10.1.  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".

Rajagopalan, et al.     Expires 28 December 2024               [Page 12]
Internet-Draft                Flow Metadata                    June 2024

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

Rajagopalan, et al.     Expires 28 December 2024               [Page 13]
Internet-Draft                Flow Metadata                    June 2024

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

                          Table 1: Initial Values

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

Rajagopalan, et al.     Expires 28 December 2024               [Page 14]
Internet-Draft                Flow Metadata                    June 2024

   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.

11.  References

11.1.  Normative References

   [CDDL]     Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/rfc/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

11.2.  Informative References

   [CBOR]     Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/rfc/rfc8949>.

   [I-D.herbert-host2netsig]
              Herbert, T., "Host to Network Signaling", Work in
              Progress, Internet-Draft, draft-herbert-host2netsig-00, 4
              October 2023, <https://datatracker.ietf.org/doc/html/
              draft-herbert-host2netsig-00>.

Rajagopalan, et al.     Expires 28 December 2024               [Page 15]
Internet-Draft                Flow Metadata                    June 2024

   [I-D.kaippallimalil-tsvwg-media-hdr-wireless]
              Kaippallimalil, J., Gundavelli, S., and S. Dawkins, "Media
              Handling Considerations for Wireless Networks", Work in
              Progress, Internet-Draft, draft-kaippallimalil-tsvwg-
              media-hdr-wireless-04, 14 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-
              kaippallimalil-tsvwg-media-hdr-wireless-04>.

   [I-D.kwbdgrr-tsvwg-net-collab-rqmts]
              Kaippallimalil, J., Wing, D., Gundavelli, S., Rajagopalan,
              S., Dawkins, S., Boucadair, M., and T. Reddy.K,
              "Requirements for Network Collaboration Signaling", Work
              in Progress, Internet-Draft, draft-kwbdgrr-tsvwg-net-
              collab-rqmts-01, 7 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-kwbdgrr-
              tsvwg-net-collab-rqmts-01>.

   [I-D.reddy-tsvwg-explcit-signal]
              Reddy.K, T., Wing, D., and M. Boucadair, "An Approach for
              Encrypted Transport Protocol Path Explicit Signals", Work
              in Progress, Internet-Draft, draft-reddy-tsvwg-explcit-
              signal-01, 7 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-reddy-tsvwg-
              explcit-signal-01>.

   [I-D.rwbr-tsvwg-signaling-use-cases]
              Rajagopalan, S., Wing, D., Boucadair, M., and T. Reddy.K,
              "Host to Network Signaling Use Cases for Collaborative
              Traffic Differentiation", Work in Progress, Internet-
              Draft, draft-rwbr-tsvwg-signaling-use-cases-02, 17 March
              2024, <https://datatracker.ietf.org/doc/html/draft-rwbr-
              tsvwg-signaling-use-cases-02>.

   [I-D.wing-cidfi]
              Wing, D., Reddy.K, T., and M. Boucadair, "Framework for
              CID Flow Indicator (CIDFI)", Work in Progress, Internet-
              Draft, draft-wing-cidfi-04, 14 December 2023,
              <https://datatracker.ietf.org/doc/html/draft-wing-cidfi-
              04>.

   [JSON]     Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8259>.

Rajagopalan, et al.     Expires 28 December 2024               [Page 16]
Internet-Draft                Flow Metadata                    June 2024

   [LOSSY-QUIC]
              Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
              Datagram Extension to QUIC", RFC 9221,
              DOI 10.17487/RFC9221, March 2022,
              <https://www.rfc-editor.org/rfc/rfc9221>.

   [QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [RELIABLE-RTP]
              Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              DOI 10.17487/RFC4588, July 2006,
              <https://www.rfc-editor.org/rfc/rfc4588>.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <https://www.rfc-editor.org/rfc/rfc768>.

   [RFC7104]  Begen, A., Cai, Y., and H. Ou, "Duplication Grouping
              Semantics in the Session Description Protocol", RFC 7104,
              DOI 10.17487/RFC7104, January 2014,
              <https://www.rfc-editor.org/rfc/rfc7104>.

   [RFC7197]  Begen, A., Cai, Y., and H. Ou, "Duplication Delay
              Attribute in the Session Description Protocol", RFC 7197,
              DOI 10.17487/RFC7197, April 2014,
              <https://www.rfc-editor.org/rfc/rfc7197>.

   [RFC7198]  Begen, A. and C. Perkins, "Duplicating RTP Streams",
              RFC 7198, DOI 10.17487/RFC7198, April 2014,
              <https://www.rfc-editor.org/rfc/rfc7198>.

   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
              March 2017, <https://www.rfc-editor.org/rfc/rfc8085>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/rfc/rfc8200>.

   [RFC8304]  Fairhurst, G. and T. Jones, "Transport Features of the
              User Datagram Protocol (UDP) and Lightweight UDP (UDP-
              Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018,
              <https://www.rfc-editor.org/rfc/rfc8304>.

Rajagopalan, et al.     Expires 28 December 2024               [Page 17]
Internet-Draft                Flow Metadata                    June 2024

   [RFC8911]  Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
              Akhter, "Registry for Performance Metrics", RFC 8911,
              DOI 10.17487/RFC8911, November 2021,
              <https://www.rfc-editor.org/rfc/rfc8911>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [RFC9221]  Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
              Datagram Extension to QUIC", RFC 9221,
              DOI 10.17487/RFC9221, March 2022,
              <https://www.rfc-editor.org/rfc/rfc9221>.

   [RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
              STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9293>.

   [RFC9543]  Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
              Makhijani, K., Contreras, L., and J. Tantsura, "A
              Framework for Network Slices in Networks Built from IETF
              Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
              <https://www.rfc-editor.org/rfc/rfc9543>.

   [RTP]      Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <https://www.rfc-editor.org/rfc/rfc3550>.

   [SCONEPRO] "SCONEPRO Working Group Charter", 2 February 2024,
              <https://datatracker.ietf.org/group/sconepro/about/>.

Appendix A.  Examples of Host-to-Network Metadata Encoding

A.1.  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:

Rajagopalan, et al.     Expires 28 December 2024               [Page 18]
Internet-Draft                Flow Metadata                    June 2024

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

           Table 2: Example Values for Video Streaming Metadata

   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:

Rajagopalan, et al.     Expires 28 December 2024               [Page 19]
Internet-Draft                Flow Metadata                    June 2024

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

A.2.  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:

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

         Table 3: 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  |
      +-------------------+------------+--------------+------------+

          Table 4: Example Values for Interactive A/V, upstream

   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:

Rajagopalan, et al.     Expires 28 December 2024               [Page 20]
Internet-Draft                Flow Metadata                    June 2024

      +===================+============+==============+============+
      |    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  |
      +-------------------+------------+--------------+------------+

         Table 5: Example Values for Interactive A/V with picture
                            sharing, upstream

   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
     }
   }

Rajagopalan, et al.     Expires 28 December 2024               [Page 21]
Internet-Draft                Flow Metadata                    June 2024

   Audio:

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

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

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

           Table 6: Example Values for live streaming of video
                             preferred event

   Metadata for live-streaming that prefers audio over video: (eg.
   Music Concert)

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

           Table 7: Example Values for live streaming of audio
                             preferred event

Rajagopalan, et al.     Expires 28 December 2024               [Page 22]
Internet-Draft                Flow Metadata                    June 2024

A.4.  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:

   +===========+==========+==============+==========+==================+
   |  Traffic  |Importance| PacketNature |PacketType|     Comments     |
   |    type   |          |              |          |                  |
   +===========+==========+==============+==========+==================+
   |   Glyph   |   high   |   realtime   | reliable | The frames that  |
   |  critical |          |              |          |  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|   high   |     keep     |unreliable|                  |
   |    (or    |          |              |          |                  |
   | streaming)|          |              |          |                  |
   |   audio   |          |              |          |                  |
   +-----------+----------+--------------+----------+------------------+
   |   Haptic  |   high   |   discard    |unreliable|   Virtualizing   |
   |  feedback |          |              |          | 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  |

Rajagopalan, et al.     Expires 28 December 2024               [Page 23]
Internet-Draft                Flow Metadata                    June 2024

   |           |          |              |          |  it makes more   |
   |           |          |              |          |      sense       |
   +-----------+----------+--------------+----------+------------------+
   |Interactive|   low    |     keep     |unreliable|    Video key     |
   |    (or    |          |              |          | frames form the  |
   | streaming)|          |              |          |  base frames of  |
   | video key |          |              |          |   a video upon   |
   |   frame   |          |              |          |  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|   low    |   discard    |unreliable|      Video       |
   |    (or    |          |              |          |    predictive    |
   | streaming)|          |              |          |  frames can be   |
   |   video   |          |              |          |   lost, which    |
   | predictive|          |              |          | would result in  |
   |   frame   |          |              |          |   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      |

Rajagopalan, et al.     Expires 28 December 2024               [Page 24]
Internet-Draft                Flow Metadata                    June 2024

   |           |          |              |          |    predictive    |
   |           |          |              |          |     frames.      |
   +-----------+----------+--------------+----------+------------------+
   |   Glyph   |   low    |   discard    |Unreliable|  The smoothing   |
   | 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.     |
   +-----------+----------+--------------+----------+------------------+

         Table 8: Example Values for Remote Desktop Virtualization
                         Metadata, server to client

   Encoding:

   Glyph critical:

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

Rajagopalan, et al.     Expires 28 December 2024               [Page 25]
Internet-Draft                Flow Metadata                    June 2024

   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
     }
   }

Appendix B.  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.

Rajagopalan, et al.     Expires 28 December 2024               [Page 26]
Internet-Draft                Flow Metadata                    June 2024

   The example shown in Figure 2 indicates a CIR (1 Mbps) for the
   requesting user:

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

     Figure 2: Example of Network-to-Host Metadata for Video Streaming

Authors' Addresses

   Sridharan Rajagopalan
   Cloud Software Group Holdings, Inc.
   United States of America
   Email: sridharan.girish@gmail.com

   Dan Wing
   Cloud Software Group Holdings, Inc.
   United States of America
   Email: danwing@gmail.com

   Mohamed Boucadair
   Orange
   France
   Email: mohamed.boucadair@orange.com

   Tirumaleswar Reddy
   Nokia
   India
   Email: kondtir@gmail.com

   Luis Miguel Contreras Murillo
   Telefonica
   Spain
   Email: luismiguel.contrerasmurillo@telefonica.com

Rajagopalan, et al.     Expires 28 December 2024               [Page 27]