Internet DRAFT - draft-rwbr-sconepro-flow-metadata
draft-rwbr-sconepro-flow-metadata
Network Working Group S. Rajagopalan
Internet-Draft D. Wing
Intended status: Standards Track Cloud Software Group
Expires: 5 September 2024 M. Boucadair
Orange
T. Reddy
Nokia
4 March 2024
Flow Metadata for Collaborative Host/Network Signaling
draft-rwbr-sconepro-flow-metadata-00
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 5 September 2024 [Page 1]
Internet-Draft Flow Metadata March 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. Metadata Structure . . . . . . . . . . . . . . . . . . . . . 5
4. Host-to-Network Metadata . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . 8
4.3.2. Reliable Traffic . . . . . . . . . . . . . . . . . . 8
4.3.2.1. Network Treatment . . . . . . . . . . . . . . . . 9
5. Network to Host Metadata . . . . . . . . . . . . . . . . . . 9
5.1. Downlink Bitrate ('DownlinkBitrate') . . . . . . . . . . 9
5.1.1. Units . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.2. Host Treatment . . . . . . . . . . . . . . . . . . . 9
5.2. Prefer Alternate Path ('pref-alt-path') . . . . . . . . . 10
5.2.1. Host Treatment . . . . . . . . . . . . . . . . . . . 10
Rajagopalan, et al. Expires 5 September 2024 [Page 2]
Internet-Draft Flow Metadata March 2024
6. Guidance For Mapping Metadata to Specific Signaling
Protocols . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Implementation Impact of Metadata . . . . . . . . . . . . . . 10
7.1. Reliable/Unreliable set by the respective transport level
protocol . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Offloading Loss-Avoidance to the network . . . . . . . . 11
8. Manageability Considerations . . . . . . . . . . . . . . . . 11
8.1. Impact on Network Operation . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10.1. Metadata for Collaborative Host/Network Signaling Registry
Group . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.2. Flow Metadata Registry . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Normative References . . . . . . . . . . . . . . . . . . . . . 14
Informative References . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Examples of Host-to-Network Metadata Encoding . . . 17
A.1. Video Streaming . . . . . . . . . . . . . . . . . . . . . 17
A.2. Interactive Gaming or Audio/Video . . . . . . . . . . . . 19
A.3. Remote Desktop Virtualization . . . . . . . . . . . . . . 20
Appendix B. Example of Network-to-Host Metadata for Video
Streaming . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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:
Rajagopalan, et al. Expires 5 September 2024 [Page 3]
Internet-Draft Flow Metadata March 2024
* 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.
Rajagopalan, et al. Expires 5 September 2024 [Page 4]
Internet-Draft Flow Metadata March 2024
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
Rajagopalan, et al. Expires 5 September 2024 [Page 5]
Internet-Draft Flow Metadata March 2024
; 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"
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.
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.
Rajagopalan, et al. Expires 5 September 2024 [Page 6]
Internet-Draft Flow Metadata March 2024
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.
* 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.
Rajagopalan, et al. Expires 5 September 2024 [Page 7]
Internet-Draft Flow Metadata March 2024
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.
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.
Rajagopalan, et al. Expires 5 September 2024 [Page 8]
Internet-Draft Flow Metadata March 2024
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.
The nominal bitrate is calculated over each second, whereas the burst
bitrate is calculated over the signaled interval (burst-duration).
For either measurement, packets can arrive at the start of a second,
as near as possible behind each other, and the remaining portion of
that second could have no packets transmitted.
5.1.1. Units
Bitrate is expressed in Mbps and duration is in milliseconds.
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.
Rajagopalan, et al. Expires 5 September 2024 [Page 9]
Internet-Draft Flow Metadata March 2024
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
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.
Rajagopalan, et al. Expires 5 September 2024 [Page 10]
Internet-Draft Flow Metadata March 2024
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. 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".
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.
Rajagopalan, et al. Expires 5 September 2024 [Page 11]
Internet-Draft Flow Metadata March 2024
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 5 September 2024 [Page 12]
Internet-Draft Flow Metadata March 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 5 September 2024 [Page 13]
Internet-Draft Flow Metadata March 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.
Acknowledgments
To be completed.
References
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>.
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>.
Rajagopalan, et al. Expires 5 September 2024 [Page 14]
Internet-Draft Flow Metadata March 2024
[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>.
[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.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,
"Signaling Use Cases for Collaborative Traffic
Differentiation", Work in Progress, Internet-Draft, draft-
rwbr-tsvwg-signaling-use-cases-00, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-rwbr-tsvwg-
signaling-use-cases-00>.
[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>.
[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>.
Rajagopalan, et al. Expires 5 September 2024 [Page 15]
Internet-Draft Flow Metadata March 2024
[MASQUE] Pauly, T., Rosenberg, E., and D. Schinazi, "QUIC-Aware
Proxying Using HTTP", Work in Progress, Internet-Draft,
draft-ietf-masque-quic-proxy-01, 12 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-masque-
quic-proxy-01>.
[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 5 September 2024 [Page 16]
Internet-Draft Flow Metadata March 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>.
[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 and the table values below explained in
detail in [I-D.rwbr-tsvwg-signaling-use-cases].
Rajagopalan, et al. Expires 5 September 2024 [Page 17]
Internet-Draft Flow Metadata March 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 5 September 2024 [Page 18]
Internet-Draft Flow Metadata March 2024
metadata = {
"metadata-type": 1,
"Application Metadata": {
"importance": false,
"reliable": false,
"prefer-keep": false
}
}
A.2. Interactive Gaming or Audio/Video
The use case requirements and the table values below explained in
detail in [I-D.rwbr-tsvwg-signaling-use-cases].
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
Encoding:
Video key frame:
metadata = {
"metadata-type": 1,
"Application Metadata": {
"importance": false,
"reliable": true,
"realtime": true
}
}
Video delta frame:
Rajagopalan, et al. Expires 5 September 2024 [Page 19]
Internet-Draft Flow Metadata March 2024
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. 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 and the table values below explained in
detail in [I-D.rwbr-tsvwg-signaling-use-cases].
+===========+==========+==============+==========+==================+
| 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.** |
+-----------+----------+--------------+----------+------------------+
Rajagopalan, et al. Expires 5 September 2024 [Page 20]
Internet-Draft Flow Metadata March 2024
|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 |
| | | | | 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 |
Rajagopalan, et al. Expires 5 September 2024 [Page 21]
Internet-Draft Flow Metadata March 2024
| (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 |
| | | | | 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 |
Rajagopalan, et al. Expires 5 September 2024 [Page 22]
Internet-Draft Flow Metadata March 2024
| | | | | glyph smoothing |
| | | | | elements. |
+-----------+----------+--------------+----------+------------------+
Table 4: 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
}
}
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:
Rajagopalan, et al. Expires 5 September 2024 [Page 23]
Internet-Draft Flow Metadata March 2024
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.
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
}
}
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
Rajagopalan, et al. Expires 5 September 2024 [Page 24]
Internet-Draft Flow Metadata March 2024
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
Rajagopalan, et al. Expires 5 September 2024 [Page 25]
