Flow Metadata for Collaborative Host/Network Signaling

Status of This Memo

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

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 5 September 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

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 signifcant 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 differented treatment.¶

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, [MASQUE] proxies).¶

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, 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 deferential treatment to those packets 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.¶

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

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
; 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 =  {
  nominal: uint,  ; Mbps
  ? burst-d => burst-info
}

burst-info = {
  burst: uint,          ; Mbps
  burstDuration: uint   ; milliseconds
}

$$metadata-extensions //= (
   ? downlinkBitrate => Bitrate,
; 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.¶

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

5. Network to Host Metadata

6. Guidance For Mapping Metadata to Specific Signaling Protocols

TBC.¶

7. Implementation Impact of Metadata

8. Manageability Considerations

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

Acknowledgments

To be completed.¶

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

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

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

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

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

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

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

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

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

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

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

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

The example shown in Figure 2 indicates the burst bandwidth (2 Mbps), burst duration (3 seconds), and nominal (non-burst) bandwidth (1 Mbps) for the requesting user:¶

{
  "downlinkBitrate": {
    "nominal": 1024,
    "burst": 2048,
    "burstDuration": 3000
  }
}

Authors' Addresses