Internet DRAFT - draft-kaippallimalil-tsvwg-media-hdr-wireless
draft-kaippallimalil-tsvwg-media-hdr-wireless
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-
rtp-over-quic-08>.
[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, <https://datatracker.ietf.org/doc/html/
draft-ietf-tsvwg-udp-options-28>.
[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>.
[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,
<https://www.rfc-editor.org/rfc/rfc5905>.
[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>.
Informative References
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/rfc/rfc8799>.
[RFC8854] Uberti, J., "WebRTC Forward Error Correction
Requirements", RFC 8854, DOI 10.17487/RFC8854, January
2021, <https://www.rfc-editor.org/rfc/rfc8854>.
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,
<https://www.rfc-editor.org/rfc/rfc9335>.
[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]
