Transport and Services Working Group J. Kaippallimalil Internet-Draft Futurewei Intended status: Informational S. Gundavelli Expires: 11 February 2025 Cisco S. Dawkins Tencent America LLC 10 August 2024 Media Handling Considerations for Wireless Networks draft-kaippallimalil-tsvwg-media-hdr-wireless-05 Abstract Wireless networks like 5G cellular or Wi-Fi experience significant variations in link capacity over short intervals due to wireless channel conditions, interference, or the end-user's movement. These variations in capacity take place in the order of hundreds of milliseconds and is much too fast for end-to-end congestion signaling by itself to convey the changes for an application to adapt. Media applications on the other hand demand both high throughput and low latency, and may adjust the size and quality of a stream to network bandwidth available or dynamic change in content coded. However, catering to such media flows over a radio link with rapid changes in capacity requires the buffers and congestion to be managed carefully. Wireless networks need additional information to manage radio resources optimally to maximize network utilization and application performance. This draft provides requirements on metadata about the media transported, its scalability, privacy, and other related considerations. Note: The solution in this draft will be revised to address requirements defined in [draft-kwbdgrr-tsvwg-net-collab-rqmts]. 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://spencerdawkins.github.io/media-hdr-wireless/#go.draft- kaippallimalil-tsvwg-media-hdr-wireless.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- kaippallimalil-tsvwg-media-hdr-wireless/. Discussion of this document takes place on the TSVWG 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/. Kaippallimalil, et al. Expires 11 February 2025 [Page 1] Internet-Draft Media Header Extensions August 2024 Source for this draft and an issue tracker can be found at https://github.com/https://github.com/SpencerDawkins/media-hdr- wireless. 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 11 February 2025. 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 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution: Metadata to Classify Media Packets . . . . . . . . 5 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Metadata Parameters . . . . . . . . . . . . . . . . . . . 7 3.2.1. Stream Flag . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. MDU-Stream Counter . . . . . . . . . . . . . . . . . 8 3.2.3. Importance . . . . . . . . . . . . . . . . . . . . . 8 3.2.4. Tolerance to Delay . . . . . . . . . . . . . . . . . 9 3.2.5. Burst Quantum Size . . . . . . . . . . . . . . . . . 10 Kaippallimalil, et al. Expires 11 February 2025 [Page 2] Internet-Draft Media Header Extensions August 2024 3.2.6. Sequence Number . . . . . . . . . . . . . . . . . . . 10 3.2.7. Timestamp . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Configuring Obfuscated Codes . . . . . . . . . . . . . . 11 3.4. Transport of Metadata . . . . . . . . . . . . . . . . . . 13 3.4.1. MED UDP Option . . . . . . . . . . . . . . . . . . . 13 3.4.2. OFC UDP Option . . . . . . . . . . . . . . . . . . . 14 3.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 14 3.6. Security Considerations . . . . . . . . . . . . . . . . . 15 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Normative References . . . . . . . . . . . . . . . . . . . . . 16 Informative References . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Wireless networks inherently experience large variations in link capacity due to several factors. These include the change in wireless channel conditions, interference between proximate cells and channels or because of the end user movement. These variations in link capacity can be in the order of a millisecond. End-to-end congestion control at the IP layer does not react fast enough to these changes when a combination of high throughput and low latency are required. Media packets on the other hand can demand both high throughput and low latency, and many emerging applications are expected to increase the strain on radio network capacity and utilization. The application can adapt, but when the feedback signal (i.e., via end-to-end congestion signaling and application level feedback) is of low resolution or frequency compared to the rapid (but transient) changes in the wireless network, the application can settle to a longer-term average sending rate that is well below the capacity available. One option is for the application to increase the sending rate to match the radio network capacity available in theory. If the application increases the sending rate aggressively, it can result in packet loss because the radio network keeps smaller buffers to ensure low latency for these flows. Low latency for the media flow and maximal usage of radio network capacity without affecting media application performance is not easy to realize in practice. With the aim of providing low latency, maximizing radio network resource utilization and improving media application performance, 3GPP studied QoS and other enhancements in the wireless network in [TR.23.700-60-3GPP]. The findings of the study are now standardized in [TR.23.501-3GPP]. The recommendations include providing the destination wireless network (where the wireless endpoint is located) with information on groups of media packets that should be handled similarly (e.g., all packets of a video I-frame), the importance of a Kaippallimalil, et al. Expires 11 February 2025 [Page 3] Internet-Draft Media Header Extensions August 2024 group of media packets relative to other such groups of packets as well as delay and packet bursts. Since media frames vary in size based on the codec, the content encoded and multistreaming, the wireless network can use the classification to make optimal choices for traffic shaping. The specification in [TR.23.501-3GPP] relies on inspecting RTP and media payload headers for classifying packets on the downlink/ destination radio network. Inspection of unencrypted RTP packets depend on deep packet inspection and require significant effort to lookup the respective headers for classifying the media packet. However, with fully encrypted media streams that use QUIC or other encrypted media transport, inspection of the media payload headers by the downlink wireless router is not possible. Figure 1 gives a high level overview of the e2e network, media transport and control plane for which additional information is needed to optimize resources in the wireless network. +--------+ E2E feedback (e.g., RCTP) +--------+ | (app) <-----------------------------------------------> (app) | | | | +--------+ | | | | | | media payload | | media payload | | | |(trnsprt)<-----------------| (QoS) |<------------------(trnsprt)| | | ( ) | | ( ) | | +--------+ ( Wireless ) +--------+ (IP Network) +--------+ Client (Network) Wireless ( ) Server (___) Router (___) CSP CAP |------------------------| |----------| Figure 1: E2E Media transport overview Media packets from the server in a Content and Application Provider (CAP) is sent to a user (client) attached to a wireless router in a Communication Service Provider (CSP). Media traffic sent downlink from the wireless router is shaped to provide optimal application performance and network utilization. In many scenarios that require low latency media delivery, the server and wireless router have established relationships and contractual agreements to optimize the delivery of media flows. For example, the CAP (Content and Application Provider) and CSP (Communication Service Provider) may have a limited domain ([RFC8799]) that manages trust and configures policies related to the delivery of content. The server and wireless router are located in networks operated by CAP and CSP respectively. The transit (IP) network in between is either Kaippallimalil, et al. Expires 11 February 2025 [Page 4] Internet-Draft Media Header Extensions August 2024 a trusted network that is managed and operated by the CSP/CAP, or the CSP/CAP use security gateways at the boundaries of their network to encrypt all traffic flowing between the CAP and CSP. Thus, the requirements are not expected to satisfy sending metadata between arbitrary servers and wireless routers located across a wide area network. 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. 2.1. Definitions CAP Content and Application Provider CSP Communication Service Provider MDU Media Data Unit; a unit of application information. An MDU may span multiple packets and are also sometimes referred to as media frames. Traffic shaping in this document refers to QoS management at the wireless router to delay or drop packets (or groups of packets) of lower priority to achieve bounded latency and high throughput. 3. Solution: Metadata to Classify Media Packets 3.1. Overview Section 1 has described the need for additional information to optimally handle low latency, high bandwidth flows in the wireless network due to rapid changes in link capacity in a wireless network. The aim of the solution here is to provide metadata that a wireless router on the connection termination side can use to shape traffic optimally. Kaippallimalil, et al. Expires 11 February 2025 [Page 5] Internet-Draft Media Header Extensions August 2024 +--------+ E2E control/feedback (e.g., SDP, RCTP) +--------+ | (app) <-----------------------------------------------> (app) | | | | +------+ | | | | | | UDP-i | |UDP-i + UDP-o/metadata| | | |(trnsprt)<----------------| (QoS)|<<<<<<<<<<<<<<<<<<<<<<(trnsprt)| | | ( ) | | ( ) | | +--------+ ( Wireless ) +------+ (IP Network) +--------+ Client (Network) Wireless ( ) Server (___) Router (___) CSP CAP |------------------------| |----------| Figure 2: UDP Media Payload and Metadata in outer UDP Packet Figure 2 outlines the scenario where a media packet from a server (e.g., a media server or relay) is sent to a client (i.e., a wireless endpoint). The server is located at a CAP (Content and Application Provider) and the client is at a CSP (Communications Service Provider) with a transit/IP network in between as in Figure 2. Media packets with low latency and high bandwidth requirements are sent from the server to client in UDP packets (UDP inner, UDP-i in Figure 2). Metadata is sent in an outer UDP encapsulation (UDP outer, UDP-o in Figure 2). The wireless router on the connection termination side uses the metadata including importance (or relative priority), packet burst size and delay tolerance to assist in shaping downstream traffic. Media frames that consist of multiple packets get the same QoS treatment when MDU/media frame information is sent by the server. An alternative is for the server to send metadata to differentiate multiple streams and provide related QoS treatment. The metadata in this solution support both options and the metadata parameters are described in Section 3.2. There two UDP options proposed here to transport the metadata. One option uses a new UDP option (MED) that send the metadata unencrypted between the server and wireless router. When this option is chosen, the CAP, CSP and the IP transit network connecting them have the means to ensure that the traffic is secure. For example, the server and wireless router located in adjacent edge data centers and connected by a managed IP network and bulk encryption of packets between the data centers. Transport using MED is described in Section 3.4.1. When there are fewer trust guarantees on the metadata path (or zero trust) between server and wireless router, the recommendation is to use metadata that is obfuscated (OFS). This would use a new UDP Kaippallimalil, et al. Expires 11 February 2025 [Page 6] Internet-Draft Media Header Extensions August 2024 option (OFS) and requires the secure configuration of obfuscated codes as described in Section 3.3. Transport using OFC is described in Section 3.4.2. The MED and OFC UDP options are both able to convey relative priority (importance), tolerance to delay, size of a burst of packets and information to derive jitter and detect loss of packets. Both MED and OFC support the above information for either media frames/MDU or streams. MED does not require any preconfigured information but a control plane configuration (out of scope here) may be used to limit the combinations of information sent. OFC on the other hand requires configured the codes that correspond to a set of information (see Section 3.3) and that automatically limits the combinations of information. Thus, the basic information in OFC or MED can be constrained by a control plane configuration to limit the possible number of states that a wireless router has to consider. Both UDP options also require no additional setup after a handover as OFCs are preconfigured per domain (CAP - CSP) and MED is sent unencrypted. 3.2. Metadata Parameters The metadata is designed to be used with both media frames (MDU) and media streams, but not at the same time. A flag (Section 3.2.1) determines if the server is using it for media frames or streams. Some of the metadata parameters are carried differently for MED (Section 3.4.1) and OFC (Section 3.4.2) due to the way that they are configured and transported. The description for each parameter covers how it is used with either MED or OFC based transport. 3.2.1. Stream Flag This metadata can be used to send information that pertains to media frames or media streams. 0 +-+ |S| +-+ Value Description ----------------------------------------------------- S Flag indicates media stream or frame 0 Media Frame 1 Media Stream Figure 3: Flag indicating media stream or media frame Kaippallimalil, et al. Expires 11 February 2025 [Page 7] Internet-Draft Media Header Extensions August 2024 When the flag is set to "0" (media frame), the parameters Importance (Section 3.2.3) and delay tolerance (Section 3.2.4) provide information about each media frame (MDU). When the flag is set tp "1" (media stream), importance and delay tolerance are for the media streams. Other parameters including burst size, sequence number and timestamp apply in all cases. 3.2.2. MDU-Stream Counter The MDU-Stream Counter field is a monotonically increasing value for every new media frame (MDU) or media stream. All the packets of an MDU or stream carry the same Counter value. The MDU-Stream Counter wraps around after 2^8 values and is thus able to represent 256 concurrent MDUs or streams. The counter field represents either an MDU counter or a stream counter based on the flag value in Section 3.2.1. This field is only applicable to unencrypted MED. When using obfuscated codes (OFS), the boundaries of an MDU are indicated by different OFS codes that are configured (see Section 3.3). 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Counter | +-+-+-+-+-+-+-+-+ Figure 4: MDU Counter The wireless network uses this field to provide consistent treatment to all packets that belong to the same MDU or stream. In some cases, based on the priority and tolerance to delay and loss, the wireless router may delay or drop the sequence of packets that has the same MDU sequence value. Media streams may carry an large or indefinite number of packets and hence the wireless router drops or delays a limited packets based on implementation. The Counter value is not itself associated to any set of media properties. 3.2.3. Importance Importance represents the media characteristics of the set of packets that that form a media data unit (MDU) or media stream relative to the characteristics of another MDU/stream. Kaippallimalil, et al. Expires 11 February 2025 [Page 8] Internet-Draft Media Header Extensions August 2024 0 0 1 2 3 4 5 +-+-+-+-+-+-+ | D | P | +-+-+-+-+-+-+ Value Description ----------------------------------------------------- D Inter-MDU Dependency 000 No dependency Information provided 001 Independent 010 Base MDU 011 Enhanced MDU (dependent on previous base MDU) P Priority level of MDU or stream 001 high priority 010 medium priority 011 low priority Figure 5: Importance Parameter The server determines the priority of a packet in terms of how critical the loss of packets of an MDU or media stream is for the application. Inter-MDU dependency has no significance for media streams and should always be set to "0". When OFCs are used, other values than independent/base/enhanced and specific to the media may be exchanged in the configuration signaling (see Section 3.3). 3.2.4. Tolerance to Delay This field conveys whether the MDU is useful if delayed in the network. Since wireless resources change significantly over very short intervals, an indication that the MDU or media stream can tolerate delays allows the wireless network to delay rather than drop. Kaippallimalil, et al. Expires 11 February 2025 [Page 9] Internet-Draft Media Header Extensions August 2024 0 0 1 +-+-+ | L | +-+-+ Value Description ----------------------------------------------------- L Delay Tolerance 00 No delay tolerance information 01 always forward 10 limited value if delayed Figure 6: Delay Budget Parameter The tolerance to delay along with data burst and importance (priority) can be used by wireless scheduler to plan for the appropriate level of resources. 3.2.5. Burst Quantum Size This field represents a continuous burst of packets and is expressed in 3 Kbyte uniform quantums. The size is chosen to provide sufficiently fine resolution to resource allocators in the wireless network and while being compact enough to represent a large burst of packets. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Burst Quantum | +-+-+-+-+-+-+-+-+ Figure 7: Burst Quantum Burst quantum with 8 bits represents burst sizes of up to 768 Kbytes (3 Kbytes * 2^8). It should be noted that a single burst may span multiple MDUs or media streams. 3.2.6. Sequence Number Sequence number is a counter that starts at arbitrary value, increases in value by 1 for each packet and wraps around after the largest number (2^16) represented in the field. Kaippallimalil, et al. Expires 11 February 2025 [Page 10] Internet-Draft Media Header Extensions August 2024 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Sequence Number The sequence number is used by the wireless router to detect loss or out of order arrival of packets. 3.2.7. Timestamp Timestamp filed contains the transmission time of the packet as defined in NTP short format [RFC5905]. The first 16 bits represent integer part in seconds, and the second 16 bits represent the fractional part of a second. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (sec) | (fraction) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Timestamp in NTP short format Jitter is the variation in delay from a mean delay in milliseconds measured over a number of packets received. The resolution of the fractional part in [RFC5905] short format far exceeds a millisecond and is sufficient for calculating jitter at the wireless router. 3.3. Configuring Obfuscated Codes Obfuscated codes should be configured between the CAP and CSP using a secure TLS channel prior to sending in UDP option in outer UDP encapsulation. Obfuscated codes (OFC) are cryptographic random numbers (128 bit) generated by the application server in the CAP and associated to a set of sensitive application metadata. The application server sends the OFC and associated sensitive metadata to the wireless router in CSP over a secure TLS channel. Sensitive metadata include start/end of MDU, relative priority/ importance and delay tolerance. An example text-based coding is shown below for readability, but binary object representations may be used in practice. Kaippallimalil, et al. Expires 11 February 2025 [Page 11] Internet-Draft Media Header Extensions August 2024 { “marker”: [“start/end”, “middle”], “importance”: [“high”, “medium”, “low”], “delTolerance”: [“high”, “low”], {“name”: OFC-1,“obfuscated-code”: 0x2a7b6a58fcd0049a0330ea7746baf01, “marker” : “start/end” “importance”: “high”, “delTolerance”: “low”} {“name”: OFC-2, “obfuscated-code”: 0xfba7763eda0050a0041dc1246dafc20, “marker” : “middle”, “importance”: “high”, “delTolerance”: “low”} } The above shows a configuration of obfuscated codes OFC-1 and OFC-2 with 'start/end' and 'middle' for high importance and low delay tolerance. In practice, multiple OFC codes corresponding to the same metadata should be used on the wire to avoid the possibility of observing the frequency /pattern of codes. For example, the application server may setup 5 OFC codes for the same set of metadata. When the application server sends metadata, it can use a random mix of the OFCs such that an observer on path cannot use frequency analysis to determine a pattern. Obfuscated codes may similarly be used to identify/distinguish between different streams (e.g., QUIC for audio, video, etc. where stream headers are not observable by the UPF). An example text encoding for this is shown below. { “streams”: [“A”, “B”], “importance”: [“high”, “low”], {“name”: OFC-11,“obfuscated-code”:0x2a7b6a58fcd0049a0330ea7746baf01, “stream” : “A” “importance”: “high”} {“name”: OFC-12,“obfuscated-code”:0xfba7763eda0050a0041dc1246dafc20, “stream” : “B”, “importance”: “low” } } The application server should initiate re-configuration of OFCs on a regular basis. Frequency of re-configuration needs to be considered further. Other metadata including burst size, sequence number and timestamp do not reveal any additional information about the media payload are not sensitive. A burst of packets can be observed on path and providing this information does not add anything that was not already observable. This field has value for a wireless network to manage radio resources if provided at the start of the burst of packets. Sequence number and timestamp also do not reveal additional information that was not otherwise available. However, all the of Kaippallimalil, et al. Expires 11 February 2025 [Page 12] Internet-Draft Media Header Extensions August 2024 the parameters here and the OFCs MUST be integrity protected to detect modification on path. Transport of OFC and related metadata is in Section 3.4.2. 3.4. Transport of Metadata Metadata is sent from the server to the wireless router in each media packet and may contain information about a media frame (MDU) or media stream. Since most if not all low latency media transport uses UDP, the transport of metadata uses one of two new UDP options defined based on [I-D.ietf-tsvwg-udp-options]. A message digest in AUTH UDP option is used with MED and OFC to allow the wireless router to detect any modification of metadata on path. Media protocols (RTP, QUIC) are not fragmented and thus the MED or OFC UDP option with metadata is carried in each packet. The media payload is limited in size to allow the addition of the MED and AUTH UDP options within the UDP packet and not exceed the MTU. 3.4.1. MED UDP Option MED is a new UDP option that conforms to [I-D.ietf-tsvwg-udp-options]. It is a SAFE option as there is no alteration of UDP payload in any manner and should be assigned a value in the 0..191 range as per [I-D.ietf-tsvwg-udp-options]. The AUTH UDP option should be used to detect any modification of data in MED. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind=TBA1 | Len=12 | RES |S| MDU-stream ctr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Importance |Del| Burst Quantum | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: MED UDP Option MED has a fixed length of 12. There are a number of bits reserved for future use in the field RES. Flag "S" denotes if the data that follows is for a media frame or a media stream. The MDU-stream counter represents MDU (media frame) or stream counter that has the same value for an MDU/stream. Importance and delay tolerance are used for both MDU and stream and described in Section 3.2.3 and Section 3.2.4. Burst quantum, sequence number and timestamp are not directly tied to one MDU or a stream and are described in Section 3.2.5, Section 3.2.6 and Section 3.2.7. Kaippallimalil, et al. Expires 11 February 2025 [Page 13] Internet-Draft Media Header Extensions August 2024 3.4.2. OFC UDP Option OFC is a new UDP option that conforms to [I-D.ietf-tsvwg-udp-options]. It is a SAFE option as there is no alteration of UDP payload in any manner and should be assigned a value in the 0..191 range as per [I-D.ietf-tsvwg-udp-options]. The AUTH UDP option should be used to detect any modification of data in OFC. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind=TBA2 | Len=16 | Obfuscated Code (OFC) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OFC (128 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OFC | Burst Quantum | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: OFC UDP Option OFC has a fixed length of 16. The obfuscated code that represents importance, delay tolerance and stream/MDU information is carried in a 128-bit OFC value described in Section 3.3. The OFC value may be configured to be information on a media frame/MDU or stream and only known to the server and wireless router. Importance and delay tolerance are used for both MDU and stream and described in Section 3.2.3 and Section 3.2.4. Burst quantum, sequence number and timestamp are not directly tied to one MDU or a stream and are described in Section 3.2.5, Section 3.2.6 and Section 3.2.7. 3.5. IANA Considerations Note: this is an Appendix, but added here for discussion on the solution. IANA request to assign new kind from UDP option registry to be set by IANA for [I-D.ietf-tsvwg-udp-options]. Kind Length Meaning ----------------------------------------------------- TBA1 12 Media Metadata (MED) TBA2 16 Obfuscated Metadata (OFC) Kaippallimalil, et al. Expires 11 February 2025 [Page 14] Internet-Draft Media Header Extensions August 2024 3.6. Security Considerations Note: this is an Appendix, but added here for discussion on the solution. The metadata itself should ensure that no additional information about either the content or the user of the content is revealed. And if the metadata is modified on path, it should be possible to detect at the wireless router. The size of a burst of packets, sequence and time information can be observed or inferred by entities on path between server and wireless router. Hence, the metadata in Burst Quantum, Sequence Number and Timestamp in both MED and OFC do not reveal information that is not otherwise possible to. However, these and all other parameter values in MED and OFC are vulnerable to modification on path. Therefore, all metadata in MED and OFC are protected by UDP option AUTH. Encrypted media payloads along with temporary IP addresses between a server and user (client) provide a measure of privacy for the content and the identity of the user. It should however be noted that media flows encrypted using RTP transports can exhibit a pattern of bursts that amounts to a signature and is vulnerable to frequency analysis. Vulnerability to frequency analysis is inherent in media sent by the server unless scheduled or multiplexed independently to each user/ recipient. The security aspects of the media payload/ transport are not in the scope of these requirements and is described here only to provide context for metadata privacy. Metadata sent using MED UDP option is vulnerable to frequency analysis to infer the contents of media payload. This is not problem with media transports based on RTP as there is a distinct pattern that can be observed and thus, MED does not reveal any further information in such cases. When using a media transport uses protocols like QUIC and also dynamically schedules media streams in such a way that the composition is unpredictable, they are not vulnerable to frequency analysis on path. MED can be used when the CAP, CSP and the IP transit network connecting them are trusted and managed to ensure that the traffic is secure from unauthorized monitoring. Kaippallimalil, et al. Expires 11 February 2025 [Page 15] Internet-Draft Media Header Extensions August 2024 The OFC UDP option can represent a single set of metadata using multiple codes. This makes it unpredictable for any observer on the wire to derive what a sequence of codes sent per packet represents as there is no meaningful pattern when observed on the wire. The OFC codes themselves are configured between server and wireless router in a secure manner using TLS. OFCs can be used when there are lower levels of trust against unauthorized monitoring across the CAP, CSP or IP transit network in between. Acknowledgments Thanks to Tiru Reddy for extensive discussions on security, metadata and UDP options formats in this draft. Thanks to Dan Wing for input on security and reliability of messages for this draft. Xavier De Foy and the authors of this draft have discussed the similarities and differences of this draft with the MoQ draft for carrying media metadata. The authors wish to thank Mike Heard, Sebastian Moeller and Tom Herbert for discussions on metadata fields, fragmentation and various transport aspects. The authors appreciate input from Marcus Ilhar and Magnus Westerlund on the need to address privacy in general and Dan Druta to consider a common transport across various host to network signaling when possible. Ruediger Geib suggested that limiting the amount of state information that a wireless router has to keep for a flow should be minimized. References Normative References [I-D.ietf-tsvwg-udp-options] Touch, J. D., "Transport Options for UDP", Work in Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-32, 21 March 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Kaippallimalil, et al. Expires 11 February 2025 [Page 16] Internet-Draft Media Header Extensions August 2024 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Informative References [draft-kwbdgrr-tsvwg-net-collab-rqmts] "Requirements for Network Collaboration Signaling, draft- kwbdgrr-tsvwg-net-collab-rqmts, https://datatracker.ietf.org/doc/draft-kwbdgrr-tsvwg-net- collab-rqmts/", July 2024. [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [TR.23.501-3GPP] "3rd Generation Partnership Project; Technical Specification Group Servies and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 18)", March 2023. [TR.23.700-60-3GPP] "Study on XR (Extended Reality) and media services (Release 18)", August 2022. Authors' Addresses John Kaippallimalil Futurewei Email: john.kaippallimalil@futurewei.com Sri Gundavelli Cisco Email: sgundave@cisco.com Spencer Dawkins Tencent America LLC Email: spencerdawkins.ietf@gmail.com Kaippallimalil, et al. Expires 11 February 2025 [Page 17]