Flow Metadata for Collaborative Host/Network Signaling

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.2. 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.¶

4.3. Packet Nature ('PacketNature')

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

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.

¶

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

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

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 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.1. Impact on Network Operation

TBC.¶

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

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

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

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:¶

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

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:¶

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:¶

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

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)¶

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

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:¶

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