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