Transport and Services Working Group J. Kaippallimalil Internet-Draft Futurewei Intended status: Informational S. Gundavelli Expires: 17 August 2024 Cisco S. Dawkins Tencent America LLC 14 February 2024 Media Handling Considerations for Wireless Networks draft-kaippallimalil-tsvwg-media-hdr-wireless-04 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. 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 17 August 2024 [Page 1] Internet-Draft Media Header Extensions February 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 17 August 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 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 3. Media Stream and Packet Handling Requirements . . . . . . . . 6 3.1. Requirement 1: Classification of downlink media frames . 6 3.1.1. Identification of media frames . . . . . . . . . . . 7 3.1.2. Relative Priority of media frames . . . . . . . . . . 7 3.1.3. Tolerance to delay of media frames . . . . . . . . . 7 3.2. Requirement 2: Classification of downlink streams . . . . 8 3.2.1. Identification of media streams . . . . . . . . . . . 8 3.2.2. Relative priority of media streams . . . . . . . . . 8 Kaippallimalil, et al. Expires 17 August 2024 [Page 2] Internet-Draft Media Header Extensions February 2024 3.2.3. Tolerance to delay of media streams . . . . . . . . . 8 3.3. Requirement 3: Size of a burst of packets . . . . . . . . 9 3.4. Requirement 4: Jitter . . . . . . . . . . . . . . . . . . 9 3.5. Requirement 5: Detection of loss of packets . . . . . . . 9 3.6. Requirement 6: Privacy Considerations . . . . . . . . . . 10 3.7. Requirement 7: Scalable to large number of media flows . 10 3.8. Requirement 8: Continuity following user mobility . . . . 10 4. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . . 12 Informative References . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Solution: Metadata to Classify Media Packets . . . . 13 A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 A.2. Metadata Parameters . . . . . . . . . . . . . . . . . . . 15 A.2.1. Stream Flag . . . . . . . . . . . . . . . . . . . . . 15 A.2.2. MDU-Stream Counter . . . . . . . . . . . . . . . . . 16 A.2.3. Importance . . . . . . . . . . . . . . . . . . . . . 16 A.2.4. Tolerance to Delay . . . . . . . . . . . . . . . . . 17 A.2.5. Burst Quantum Size . . . . . . . . . . . . . . . . . 18 A.2.6. Sequence Number . . . . . . . . . . . . . . . . . . . 18 A.2.7. Timestamp . . . . . . . . . . . . . . . . . . . . . . 19 A.3. Configuring Obfuscated Codes . . . . . . . . . . . . . . 19 A.4. Transport of Metadata . . . . . . . . . . . . . . . . . . 21 A.4.1. MED UDP Option . . . . . . . . . . . . . . . . . . . 21 A.4.2. OFC UDP Option . . . . . . . . . . . . . . . . . . . 22 A.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 22 A.6. Security Considerations . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 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 Kaippallimalil, et al. Expires 17 August 2024 [Page 3] Internet-Draft Media Header Extensions February 2024 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 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. Kaippallimalil, et al. Expires 17 August 2024 [Page 4] Internet-Draft Media Header Extensions February 2024 +--------+ 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 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 in Section 3 are not expected to satisfy sending metadata between arbitrary servers and wireless routers located across a wide area network. Section 3 provides requirements to support the provision of information/metadata sent from the CAP to the CSP to realize optimal management of radio network resources and application performance. 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. Kaippallimalil, et al. Expires 17 August 2024 [Page 5] Internet-Draft Media Header Extensions February 2024 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. Media Stream and Packet Handling Requirements Wireless networks shape traffic and schedule radio resources to adapt to rapid changes in channel conditions. When media applications demand high throughput and low latency, the rate at which an application can adapt based on congestion feedback is not sufficient to maximize application performance and utilize available capacity optimally. Information to classify packets, groups of packets or streams by priority and tolerance to delay is needed help the wireless network. The requirements here outline the information needed by the wireless network and the related requirements for privacy, performance and scalability. The assumption in the requirements below are that they apply to low latency media transports (e.g, RoQ [I-D.ietf-avtcore-rtp-over-quic]), RTP-cryptex [RFC9335] and WebRTC [RFC8854]. In the requirements below, a stream refers to a data flow from a sender to receiver (e.g., SRTP video packets, QUIC stream carrying audio). A transport connection may carry one or more (media) streams from sender to receiver. 3.1. Requirement 1: Classification of downlink media frames Feedback provided by ECN/L4S to the server (UDP sender) is not fast enough to adjust the sending rate when available wireless capacity changes significantly in very short periods of time (~ 1 millisecond). Differentiating using multiple DSCP codes does not provide the resolution required to classify media frames and adapt to changes in coding due to dynamic content or resulting from network conditions. Kaippallimalil, et al. Expires 17 August 2024 [Page 6] Internet-Draft Media Header Extensions February 2024 Relative priority of media frames, tolerance to delay, identification of media frame boundaries are provided by the application to optimize traffic shaping at the wireless router. Alternatively, an application may prefer to provide only the information about streams and their relative priority (see Section 3.2). In such cases it does not provide any information to classify media frames. 3.1.1. Identification of media frames A wireless router should treat all packets of an MDU (media frame) in the same manner for optimal application performance. Random, or tail drops that span media frame boundaries may result in the decoder being unable to decode many more media frames. The application should provide information that allows the wireless router to detect the start, end and set of packets of an MDU (media frame). In cases where the wireless network has to drop or delay processing, all packets of the MDU are treated in the same manner. 3.1.2. Relative Priority of media frames Relative importance of a packet (or media frame) provides the priority level of one media frame over another media frame in a stream. The application server determines the importance based on the media encoded in the media frame (e.g., a base layer video I-frame has higher priority than an enhanced layer P-frame). Importance may be used to determine drop priority in cases of extreme congestion in the wireless network. 3.1.3. Tolerance to delay of media frames Some media frames may be able to tolerate more delay over the wire than others (e.g., live media frames require very low latency while a background image for augmented reality may be delivered with more delay tolerance). Even when the media payload is not encrypted, the network has no means to distinguish these different requirements. If the application can indicate that an MDU can tolerate high delay the wireless router can opt to delay packets rather than drop during transient congestion periods. The application should also be able to convey that in some cases it has no specific information about relative delays, or expects the same delay tolerance for all media frames. Kaippallimalil, et al. Expires 17 August 2024 [Page 7] Internet-Draft Media Header Extensions February 2024 3.2. Requirement 2: Classification of downlink streams In some deployments, multiple media streams with different priorities are sent in a single transport connection (e.g., WebRTC [RFC8854], QUIC transports for multimodal media, audio, video, control, haptics). In such cases, an application may want to prioritize one stream over another in the event of extreme congestion (e.g., audio stream prioritized over video stream). The application may prefer to provide only the information about streams and their relative priority, and in such cases it does not provide any information to classify media frames (see Section 3.1). In this case, the application conveys to the wireless network the relative priority of media streams in a single transport connection. 3.2.1. Identification of media streams Multiple streams of media are sometimes delivered over a single transport connection where the payload and stream headers are encrypted (e.g., QUIC). A wireless router cannot identify the streams by inspecting the header fields (e.g., connection identifier in QUIC). The application should provide a means to identify one encrypted media stream from another to allow the wireless router to provide differentiated QoS treatment for each stream. 3.2.2. Relative priority of media streams Relative importance of a media stream is the priority level of one media stream over another stream in the transport connection. The application server determines the importance based on the media encoded in the stream. Importance may be used to determine drop priority in cases of extreme congestion in the wireless network. 3.2.3. Tolerance to delay of media streams Some media streams may be able to tolerate more delay over the wire than others (e.g., a stream carrying a background image for augmented reality may be delivered with more delay tolerance). Even when the media payload is not encrypted, the network has no means to distinguish these different requirements. Kaippallimalil, et al. Expires 17 August 2024 [Page 8] Internet-Draft Media Header Extensions February 2024 If the application can indicate that a stream can tolerate high delay the wireless router can opt to delay packets rather than drop during transient congestion periods. The application should also be able to convey that in some cases it has no specific information about relative delays, or expects the same delay tolerance for all media streams. 3.3. Requirement 3: Size of a burst of packets Media flows can have large and unexpected variations in packet bursts due to dynamic changes in content, server estimation of network conditions and pacing behavior. Encoding of live video, and multimodal media can only increase the burst size that a server has to contend with sending out in a relative smoothed out manner. The burst size is observable on the wire, but can only be determined by the end of the burst of packets. Wireless networks on the other hand cannot reserve resources for the maximum burst size as that will lead to poor utilization of the radio resources. The server should provide expected size of a burst of packets at the beginning of the burst to allow the scheduler to reserve sufficient resources (and avoid have too few resources that lead to a tail drop). Application servers that are not able to reliably estimate the burst size at the beginning of a burst should not provide any information about the burst size. 3.4. Requirement 4: Jitter Packets of a burst that experience a high level of jitter are likely experiencing higher than usual delay before arriving at the wireless network. The wireless router can use packet timestamps to derive jitter and optimize downlink scheduling. A timestamp with resolution to the microsecond level (e.g., short format in [RFC5905]) is sufficient for these purposes. 3.5. Requirement 5: Detection of loss of packets The wireless router should be aware of any loss of packets belonging to a media frame. For example, the loss of a packet that is a start or end of a media frame can cause confusion in estimating media frame boundaries. However, the wireless router does not re-order packets arriving out of order at the wireless router as this will increase latency experienced by the flow. The server should provide a sequence number that identifies the sequence of packets for a transport connection carrying the media flows. Kaippallimalil, et al. Expires 17 August 2024 [Page 9] Internet-Draft Media Header Extensions February 2024 3.6. Requirement 6: Privacy Considerations 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 (e.g., encrypted video payloads in SRTP) exhibit a pattern of bursts and intervals that amounts to a signature and is vulnerable to frequency analysis. To avoid this kind of frequency analysis, media sent by the server would need to be scheduled or multiplexed differently to each user/recipient. This may be possible in transports like QUIC which allows flexibility in scheduling each stream. Transports like QUIC also fully encrypt the entire stream and therefore no media headers are observable on path either. 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. Privacy considerations for the metadata itself should ensure that no additional information about either the content or the user of the content is revealed. Some of the metadata like the size of a burst of packets, sequence number and timestamp are information that can be plainly observed or inferred by an entity on path. These and all other metadata sent from server to the wireless router are vulnerable to modification on path. All metadata should therefore have secure integrity protection (e.g., a secure message digest) to detect any modification or tampering on path. 3.7. Requirement 7: Scalable to large number of media flows There may be a large number of media flows handled by the server and wireless router, and more generally between CAP and CSP. Per flow information (state) at a wireless router for optimizing the flow can negate the advantages offered as the number of flows handled increase. The metadata other state information that a wireless router has to maintain for each additional media flow it handles should be very low or none. 3.8. Requirement 8: Continuity following user mobility The general trend in wireless networks is to distribute the wireless router closer to the user. This can help with low latency but it results in more handovers from one router to another as the user moves. The number of handovers also increase as a user moves faster or the media session lasts longer. There should no additional delay incurred during handover in configuring/setting up the metadata of a media session in progress. Kaippallimalil, et al. Expires 17 August 2024 [Page 10] Internet-Draft Media Header Extensions February 2024 4. Non-Requirements Metadata resulting from these requirements are to be used by the wireless router (connection termination side) for shaping the downlink traffic. However, this document does not specify how this information should be used by the wireless router. Similarly, an application provides this information to the transport stack on the application server. How the application conveys this information to the transport stack is out of scope of these requirements. Control plane feedback with measurements of packets lost and delay incurred may affect the sending rate. Dropping less important application frames in the presence of very short term changes of available bandwidth should not directly lead to lowering the sending rate itself. Some work may be needed to allow the application server to differentiate between the short term variability and the presence of congestion in the network, but is not in the scope of these requirements. 5. IANA Considerations None. 6. Security Considerations This document has no security considerations. 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 Kaippallimalil, et al. Expires 17 August 2024 [Page 11] Internet-Draft Media Header Extensions February 2024 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-avtcore-rtp-over-quic] Ott, J., Engelbart, M., and S. Dawkins, "RTP over QUIC (RoQ)", Work in Progress, Internet-Draft, draft-ietf- avtcore-rtp-over-quic-08, 12 February 2024, . [I-D.ietf-tsvwg-udp-options] Touch, J. D., "Transport Options for UDP", Work in Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-28, 17 November 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [RFC8854] Uberti, J., "WebRTC Forward Error Correction Requirements", RFC 8854, DOI 10.17487/RFC8854, January 2021, . Kaippallimalil, et al. Expires 17 August 2024 [Page 12] Internet-Draft Media Header Extensions February 2024 [RFC9335] Uberti, J., Jennings, C., and S. Murillo, "Completely Encrypting RTP Header Extensions and Contributing Sources", RFC 9335, DOI 10.17487/RFC9335, January 2023, . [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. Appendix A. Solution: Metadata to Classify Media Packets A.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. +--------+ 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 Kaippallimalil, et al. Expires 17 August 2024 [Page 13] Internet-Draft Media Header Extensions February 2024 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 Appendix A.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 Appendix A.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 option (OFS) and requires the secure configuration of obfuscated codes as described in Appendix A.3. Transport using OFC is described in Appendix A.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 Appendix A.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 Kaippallimalil, et al. Expires 17 August 2024 [Page 14] Internet-Draft Media Header Extensions February 2024 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. A.2. Metadata Parameters This section describes the metadata parameters to satisfy the requirements identified in Section 3. The metadata is designed to be used with both media frames (MDU) and media streams, but not at the same time. A flag (Appendix A.2.1) determines if the server is using it for media frames or streams. Some of the metadata parameters are carried differently for MED (Appendix A.4.1) and OFC (Appendix A.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. A.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 When the flag is set to "0" (media frame), the parameters Importance (Appendix A.2.3) and delay tolerance (Appendix A.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. Kaippallimalil, et al. Expires 17 August 2024 [Page 15] Internet-Draft Media Header Extensions February 2024 A.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 Appendix A.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 Appendix A.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. A.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 17 August 2024 [Page 16] Internet-Draft Media Header Extensions February 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 Appendix A.3). A.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 17 August 2024 [Page 17] Internet-Draft Media Header Extensions February 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. A.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. A.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 17 August 2024 [Page 18] Internet-Draft Media Header Extensions February 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. A.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. A.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 17 August 2024 [Page 19] Internet-Draft Media Header Extensions February 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 17 August 2024 [Page 20] Internet-Draft Media Header Extensions February 2024 the parameters here and the OFCs MUST be integrity protected to detect modification on path. Transport of OFC and related metadata is in Appendix A.4.2. A.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. A.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 Appendix A.2.3 and Appendix A.2.4. Burst quantum, sequence number and timestamp are not directly tied to one MDU or a stream and are described in Appendix A.2.5, Appendix A.2.6 and Appendix A.2.7. Kaippallimalil, et al. Expires 17 August 2024 [Page 21] Internet-Draft Media Header Extensions February 2024 A.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 Appendix A.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 Appendix A.2.3 and Appendix A.2.4. Burst quantum, sequence number and timestamp are not directly tied to one MDU or a stream and are described in Appendix A.2.5, Appendix A.2.6 and Appendix A.2.7. A.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 17 August 2024 [Page 22] Internet-Draft Media Header Extensions February 2024 A.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 17 August 2024 [Page 23] Internet-Draft Media Header Extensions February 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. 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 17 August 2024 [Page 24]