Transport and Services Working Group J. Kaippallimalil
Internet-Draft Futurewei
Intended status: Informational D. Wing
Expires: 23 January 2025 Cloud Software Group
S. Gundavelli
Cisco
S. Rajagopalan
Cloud Software Group
S. Dawkins
Tencent America LLC
M. Boucadair
Orange
22 July 2024
Requirements for Network Collaboration Signaling
draft-kwbdgrr-tsvwg-net-collab-rqmts-02
Abstract
Wireless networks (e.g., cellular or WLAN) experience significant but
transient variations in link quality and have policy constraints
(e.g., bandwidth) that affect user experience. Collaborative
signaling (e.g., host-to-network and server-to-network) can improve
the user experience by informing the network about the nature and
relative importance of packets (frames, streams, etc.) without having
to disclose the content of the packets. Moreover, the collaborative
signalling may be enabled so that hosts are aware of the network's
treatment of incoming packets. Also, host-to-network collaboration
can be put in place without revealing the identity of the remote
servers. This collaboration allows for differentiated services at
the network (e.g., packet discard preference), the sender (e.g.,
adaptive transmission), or through cooperation of server / host and
the network.
This document lists some use cases that illustrate the need for a
mechanism to share metadata and outlines requirements for both host-
to-network (and vice versa) and server-to-network (and vice versa).
The document focuses on intra-flow or flows bound to the same user.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-kwbdgrr-tsvwg-net-collab-
rqmts/.
Kaippallimalil, et al. Expires 23 January 2025 [Page 1]
Internet-Draft Network Collaboration Requirements July 2024
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/.
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 23 January 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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Media Streaming . . . . . . . . . . . . . . . . . . . . . 8
3.2. Interactive Media . . . . . . . . . . . . . . . . . . . . 9
3.3. Accommodate-Delay Traffic . . . . . . . . . . . . . . . . 9
3.4. User Preferences . . . . . . . . . . . . . . . . . . . . 10
3.5. Mixed Traffic . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Honoring of Metadata for Servers Behind a Gateway . . . . 11
4. Operational Considerations . . . . . . . . . . . . . . . . . 12
Kaippallimalil, et al. Expires 23 January 2025 [Page 2]
Internet-Draft Network Collaboration Requirements July 2024
4.1. Policy Enforcement . . . . . . . . . . . . . . . . . . . 12
4.2. Redundant Functions and Classification Complications . . 12
4.3. Metadata Scope . . . . . . . . . . . . . . . . . . . . . 13
4.4. Metadata Granularity . . . . . . . . . . . . . . . . . . 13
4.4.1. Application Metadata . . . . . . . . . . . . . . . . 13
4.4.2. Network Metadata . . . . . . . . . . . . . . . . . . 14
4.5. Multiple Bottlenecks . . . . . . . . . . . . . . . . . . 14
4.6. Application Interference . . . . . . . . . . . . . . . . 15
4.7. Exposure Handling . . . . . . . . . . . . . . . . . . . . 15
4.8. Privacy Considerations . . . . . . . . . . . . . . . . . 16
4.9. Scalability . . . . . . . . . . . . . . . . . . . . . . . 17
4.10. Session Continuity . . . . . . . . . . . . . . . . . . . 17
4.11. Abuse and Constraints . . . . . . . . . . . . . . . . . . 18
5. On-path Metadata Requirements . . . . . . . . . . . . . . . . 18
5.1. Host-Network Metadata . . . . . . . . . . . . . . . . . . 19
5.1.1. Priority between Flows (Inter-flow) . . . . . . . . . 19
5.1.2. Priority within a Flow (Intra-Flow) . . . . . . . . . 20
5.2. Network-Host Metadata . . . . . . . . . . . . . . . . . . 21
5.2.1. Assisted Offload . . . . . . . . . . . . . . . . . . 21
5.2.2. Network Bandwidth & Network Rate Limiting Policies . 21
5.3. Server-Network Metadata . . . . . . . . . . . . . . . . . 22
5.3.1. Identification of Media Frames and Streams . . . . . 22
5.3.2. Identification of Traffic Type without Disclosure of
the Application . . . . . . . . . . . . . . . . . . . 23
5.3.3. Relative Priority . . . . . . . . . . . . . . . . . . 23
5.3.4. Tolerance to Delay . . . . . . . . . . . . . . . . . 23
5.3.5. Burst Indication . . . . . . . . . . . . . . . . . . 24
6. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Informative References . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction
Wireless networks inherently experience large variations in link
quality 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
quality can be in the order of a millisecond or less [_5G-Lumos]
while congestion control takes several tens of milliseconds (more
than one round-trip time (RTT)) to estimate data rate. End-to-end
congestion control algorithms are far from optimal when the link
quality is highly variable in sub-RTT timeframes and the application
demands both low latency and high bandwidth (e.g., Section 2.1 of
[RFC6077]).
Kaippallimalil, et al. Expires 23 January 2025 [Page 3]
Internet-Draft Network Collaboration Requirements July 2024
It is also not practical to convey sub-RTT link changes using an end-
to-end feedback signal. As a consequence, applications settling for
a lower throughput when latency is prioritized or achieving higher
throughput at the expense of much higher delays.
With not fully encrypted packets, networks may use some heuristics to
build an "implicit signal" derived from the contents of a packet to
prioritize or otherwise shape flows. Implicit signals are not
desirable as they lead to ossification of protocols as result of
introducing unintended dependencies [RFC9419]. When packet contents
are encrypted, the approach of using implicit signals is no longer
viable.
Bandwidth constraints exist most predominantly at the access network
(e.g., radio access networks). Users who are serviced via these
networks use hosts which run various application clients; each having
different connectivity needs for an optimal user experience. These
needs are not frozen but change over time depending on the
application and even depending on how an application is used (e.g.,
user's preferences). An explicit signal to the host can help to
manage the use of available bandwidth better and better share it with
requesting applications.
Other applications like interactive media can demand both high
throughput and low latency and, in some cases, carry different media
streams (e.g., audio and video) in a single transport connection
(e.g., WebRTC [RFC8825]). There may be preferences that an
application may wish to convey, such as a higher priority for audio
over video (or the opposite) in congested networks or importance of
certain packets (e.g., video key frames). With RTP [RFC3550], the
type of media could be examined and used as an implicit signal for
determining relative priority. However, [RFC9335] defines a new
mechanism that completely encrypts RTP header extensions and
Contributing sources (CSRCs). Furthermore, a full encrypted
transport (e.g., QUIC [RFC9000]) does not expose any media header
information that on-path network elements can use for forwarding.
As mobile networks primarily service battery-operated devices, the
same information is useful to those networks even without network
congestion, as the information can inform the base station to
aggregate packet transmission to allow the mobile device to briefly
power down (sleep) its radio.
Kaippallimalil, et al. Expires 23 January 2025 [Page 4]
Internet-Draft Network Collaboration Requirements July 2024
Also, traffic patterns in some emerging applications can vary
significantly during the session. For example, live media or AI-
generated content can have significant dynamic variations and
potentially aperiodic frames. Information gleaned from unencrypted
media packets and headers that wireless networks used in the past to
optimize traffic shaping and scheduling are not exposed in encrypted
communications.
|
3GPP/mobile network
+--------------------|----------------------+
|+-- ---+ | +-----+ +-----+ |
||client+-----------(B)--+radio+----+ UPF | |
|+------+ | +-----+ +--+--+ |
+--------------------|-----------------|----+
| |
Wireless home/ISP network |
+--------------------|-----------+ | | |
|+--- --+ +----+ | +------+ | +---+--+ | +------+ | +------+
||client+-(B)+WLAN+-(B)-+router+---+router+---+router+---+server|
|+------+ +----+ | +------+ | +------+ | +------+ | +------+
+--------------------|-----------+ | |
| | |
| | Transit | Content
User device/Network | MNO/ISP Network | Network | Network
Figure 1
Figure 1 shows where such bandwidth and performance constraints
usually exist with a "B" (for Bottleneck) in 3GPP/mobile networks and
WLAN/ISP networks. When a bottleneck exists temporarily, the network
has no choice but to discard or delay packets -- which can harm
certain flows and, thus, lead to suboptimal perceived experience. In
this document, this is termed 'reactive policy'.
A network attachment represents the communication link between hosts
(client) and network (router) over which a connection policy
(including QoS) is applied to flows within that network attachment.
A network attachment may be established using control plane signaling
between the client and the network (access) router and is out of
scope of this document. Transport flows over a network attachment
may consist of multiple streams such as video or audio. Figure 2
shows a high level view of network attachments, flows, and QoS/policy
discussed in Section 5.
Kaippallimalil, et al. Expires 23 January 2025 [Page 5]
Internet-Draft Network Collaboration Requirements July 2024
The requirements in Section 5 apply to data units like frames within
a flow, but not between flows. Specifically, this document does not
discuss flows of distinct hosts/users.
+----------+ +-----------------+
|+----+ | | +-------------+ |
|| A1 |--+ | | | QoS, Policy | |
|+-+--+A2| | | +---+-----+---+ | +------+
| |+-+--+ | Network | | | | |srv-A2|
| | | |attachment| v | | +--+---+
| | | *************************|**** | |
| | +------------- flow-x2 -----|-------------------+ +------+
| +------------ flow-x1 ---------|-----------------------+srv-A1|
| *************************|**** | +--+---+
+-Client-1-+ | | | |
| | | |
+----------+ Network attachment V | |
|+----+ ****************************** | |
|| A1 +------------ flow-x3 ---------------------------------+
|+----+ ****************************** |
+----------+ +-----------------+
Client-2 Router
Figure 2
Figure 2 shows "Client-1" and "Client-2" that negotiate connection
policy (e.g., QoS) and other aspects like mobility handling, charging
applied to flows in that network attachment. "Client-1" has "flow-
x1" and "flow-x2" over its network attachment while "Client-2" has
"flow-x3". The requirements in this document focuses on on-path
collaboration signals that apply to data units such as media frames
within flows like "flow-x1/x2/x3" but not between them.
In summary, the rapid variation of wireless link quality and/or
bandwidth limitations in networks along with interactive applications
that demand low latency and high throughput can lead to suboptimal
user experience. Section 3 outlines use cases to illustrate the
issues and the need for additional information per flow to allow the
network to optimize its handling.
Some of the complications that are induced by the phenomena discussed
above may be eliminated by adequate dimensioning and upgrades.
However, such upgrades may not be always (immediately) possible or
justified. Complementary mitigations are thus needed to soften these
complications by introducing some collaboration between endpoints and
networks to adjust their behaviors.
Kaippallimalil, et al. Expires 23 January 2025 [Page 6]
Internet-Draft Network Collaboration Requirements July 2024
Section 4 provides operational constraints in the network and
Section 5 describes the requirements for on-path media collaboration
signals.
2. Definitions
The document makes use of the following terms:
Discard preference: Is an indication of drop preference within a
flow when there are no sufficient network resources to handle all
competing packets of that same flow.
Intentional Management: Network policy such as (monthly) bandwidth
quota or bandwidth limit, or quality (delay and/or jitter))
assurances.
Reactive Management: Network reactions to congestion events or
protection polices under attacks, with very short to very long
durations (e.g., varying wireless and mobile air interface
conditions).
Traffic shaping: Refers in this document to QoS management at the
wireless/access router to delay or discard packets of lower
priority to achieve bounded latency and high throughput.
User Plane Function (UPF): Refers to a 3GPP element that is located
between the mobile infrastructure and the Data Network (DN) as
shown in Figure 3.
For a definitive description of 3GPP network architectures, the
reader should refer to the 3GPP's TR 23.501 [TR.23.501-3GPP].
┌─────┠┌─────┠┌─────┠┌─────┠┌─────┠┌─────â”
│NSSF │ │ NEF │ │ NRF │ │ PCF │ │ UDM │ │ AF │
└──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘
Nnssf│ Nnef│ Nnrf│ Npcf│ Nudm│ │Naf
───┴────────┴──┬─────┴──┬───────┴───┬────┴────────┴────
Nausf│ Namf│ Nsmf│
┌──┴──┠┌──┴──┠┌──┴──────â”
│AUSR │ │ AMF │ │ SMF │
└─────┘ └──┬──┘ └──┬──────┘
╱ │ │ ╲
Control Plane N1 ╱ │N2 │N4 ╲N4
â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•
User Plane ╱ │ │ ╲
┌───┠┌──┴──┠N3 ┌──┴──┠N9 ┌─────┠N6 .───.
│UE ├──┤(R)AN├─────┤ UPF ├────┤ UPF ├────( DN )
└───┘ └─────┘ └─────┘ └─────┘ `───'
Kaippallimalil, et al. Expires 23 January 2025 [Page 7]
Internet-Draft Network Collaboration Requirements July 2024
Figure 3: 5GS Architecture
3. Use Cases
3.1. Media Streaming
Streaming video contains the occasional key frame ("I-frame")
containing a full video frame. These frames are necessary to rebuild
receiver state after loss of delta frames. The key frames are
therefore more critical to deliver to the receiver than delta frames.
Streaming video also contains audio frames which can be encoded
separately and, thus, can be signaled separately (requirement: REQ-
MEDIA-KEYFRAME).
Audio is more critical than video for many applications, but its
importance (relative to other packets in the flow) is still an
application decision (requirements: REQ-MEDIA-AV-SEPARATE, REQ-MEDIA-
CLIENT-DECIDES). For example, the ability of the receiver to change
the priority by communicating to the network -- without cooperation
of the sender -- gives a hearing-impaired user the ability to adjust
video above audio.
Especially with media over QUIC, the server (or relay) sends the same
stream to many receivers, including the same metadata. Thus, when a
client needs different prioritization (e.g., video over audio or the
other way around), this is only achievable by signaling that priority
inversion from the client to the ISP router (requirement: REQ-CLIENT-
DECIDES).
Examples: live broadcast, on-demand video streaming
Requirements:
REQ-MEDIA-KEYFRAME: Video contains partial frames and full frames,
which need to be distinguished so that full frames can be
indicated to the network.
REQ-MEDIA-AV-SEPARATE: Audio can be prioritized differently than
video.
Use cases:
Kaippallimalil, et al. Expires 23 January 2025 [Page 8]
Internet-Draft Network Collaboration Requirements July 2024
1. In loss-prone networks or during reactive policy events,
retransmissions cause long delays. All packets being treated the
same can have challenges in efficiently handling/forwarding data.
Today, there is no way to identify packets which are less
important and/or loss-tolerant to prioritize packets in
challenging networks and/or during reactive events.
2. 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.
3.2. Interactive Media
Interactive media includes content that a user can actively engage
with and results in input and response actions that can be highly
delay-sensitive.
Examples: VoIP (Peer-to-Peer (P2P), group conferencing), gaming,
eXtended Reality (XR).
Requirements:
REQ-PACKET-NATURE: The receiver indicates that a flow can be allowed
to be delayed/buffered (bulk data transfer) or not (interactive
traffic) and requests that the network honors the incoming flow's
per-packet signals, which prevents denial of service of mis-marked
incoming flows.
Use cases:
1. A mobile/roaming user prioritizes audio over video during a VoIP
call to have a seamless meeting experience.
3.3. Accommodate-Delay Traffic
Accommodate-Delay traffic includes content that is more resilient to
buffering and delays (e.g., file copy, file download) compared to
interactive traffic. This traffic can be buffered in favor of
improved interactivity, without significant impact to the user
experience. It is least sensitive to buffer bloating.
Requirement: REQ-PACKET-NATURE as defined previously.
Use cases:
Kaippallimalil, et al. Expires 23 January 2025 [Page 9]
Internet-Draft Network Collaboration Requirements July 2024
1. A remote desktop user prioritizes graphics update over an on-
going file copy operation.
2. User application in foreground is given priority over downloading
software updates.
3.4. User Preferences
A game or VoIP application may want to signal different metadata for
the same type of packet in each direction. For example, for a game,
video in the server-to-client direction might be more important than
audio, whereas input devices (e.g., keystrokes) might be more
important than audio. Each user can have varied preferences for the
same type of data originating from the server.
Determination of such preferences is outside of the scope of this
document.
Requirements:
REQ-CLIENT-DECIDES: The receiving client determines importance of
packets it receives, as the client may have changing needs over
time.
Use cases:
1. Dynamic changes to priority based on user activity is not
possible today. For example, audio packets having the same
priority when a user mutes the audio locally, or change in
priority during times of emergency where video streaming
applications share the same priority as SOS signals.
2. A user prioritizing video over audio while playing an interactive
game.
3. User's foreground application should receive priority over
background tasks. For example, a user is typing in a document
while playing a media in the background within the same session.
3.5. Mixed Traffic
Mixed traffic can contain multiple types of data flowing through the
same 5-tuple connection. They may include digital models of the real
world, multimedia content, virtualized desktop/apps, and interactive
engagement.
Kaippallimalil, et al. Expires 23 January 2025 [Page 10]
Internet-Draft Network Collaboration Requirements July 2024
In cases where the wireless network has to drop or delay processing,
all packets of the media frame or stream are treated in the same
manner.
Requirements:
REQ-PACKET-RELIABILITY: Indicate if a packet is treated as reliable
or unreliable by the application.
REQ-PACKET-NATURE: Indicate if a packet belongs to bulk traffic or
interactive traffic.
Examples: Virtual Apps and Desktops.
Use cases:
1. Document being printed/saved while being edited. The interactive
traffic has higher priority over bulk traffic).
2. File download while intearacting with the webpage. With QUIC,
this could occur with the same webserver. Interactive activity
performed with the webpage higher priority over file download.
3. In graphics remoting, Critical Glyphs (Reliable) has more
priority over Smoothing Glyphs (unreliable) during reactive
events.
4. During reactive policy events, the network can choose to drop the
packets marked unreliable by the application, thereby
prioritizing reliable packets to avoid retransmissions and
performance degradation.
3.6. Honoring of Metadata for Servers Behind a Gateway
In enterprise networks and remote desktop use case, a server can host
multiple connections with varying type of traffic. These servers are
often exposed to the Internet through some sort of a gateway-proxy
and the signaling (like DSCP bits) from these servers are often
ignored by the access/transit networks.
Requirement: REQ-CLIENT-DECIDES as defined previously.
Kaippallimalil, et al. Expires 23 January 2025 [Page 11]
Internet-Draft Network Collaboration Requirements July 2024
4. Operational Considerations
Traffic policing and shaping are enforced in ingress/egress network
points for various reasons (protect the network against attacks,
ensure conformance with a trafic profile, etc.). Out-of-profile
trafic may be discarded or assigned another class (e.g., using Lower
Effort Per-Domain Behavior (LE PDB) [RFC3662]) a bandwidth limit
among others. The exact behavior is policy-based and deployment-
specific.
The entire set of operations to manage traffic is beyond the scope of
this document. This section focuses on operational constraints that
impact server – network, and host – network modes of sending
metadata.
4.1. Policy Enforcement
Some metadata requires the network to share some hints with a host to
adjust its behavior for some specific flows. However, that metadata
may have a dependency on the service offering that is subscribed by a
user.
Let us consider the example of a bitrate for an optimized video
delivery. _Such bitrate may not be computed system-wide_ given that
flows from users with distinct service offerings (and connectivity
SLOs) may be serviced by the same network nodes. Instead, the
network needs to dynamically adjust the bitrate based on each user's
service package and connectivity SLOs to ensure optimal delivery for
all users (REQ-METADATA-ACCURACY).
Requirement: REQ-METADATA-ACCURACY.
4.2. Redundant Functions and Classification Complications
If distinct channels are used to share the metadata between a host
and a network, a network that engages in the collaborative signaling
approach will require sophisticated features to classify flows and
decide which channel is used to share metadata so that it can consume
that information.
Likewise, the network will require to implement redundant functions;
for each signaling interface.
_As such, application- and protocol-specific signaling channels are
suboptimal._ (REQ-SINGLE-CHANNEL)
Requirement: REQ-SINGLE-CHANNEL is preferred.
Kaippallimalil, et al. Expires 23 January 2025 [Page 12]
Internet-Draft Network Collaboration Requirements July 2024
4.3. Metadata Scope
An operational challenge for sharing resource-quota like metadata
(e.g., maximum bitrate) is that the network is generally not entitled
to allocate quota per-application, per-flow, per-stream, etc. that
delivered as part of an Internet connectivity service. However, the
network has a visibility about the overall network attachment (e.g.
inbound/outbound bandwidth discussed in
[I-D.ietf-opsawg-teas-attachment-circuit]).
As such, hints about resource-like metadata is bound by default to
the overall network attachment, not specific to a given application
or flow.
Most importantly, the metadata can be used by the network to
prioritize traffic within a single 5-tuple connection and metadata
cannot be leveraged for prioritization between different flows.
It is out of the scope of this document to discuss setups (e.g., 3GPP
PDU Sessions) where network attachments with Guaranteed Bit Rate
(GBR) for specific flows is provided.
Requirement:
REQ-SCOPED-METADATA: Means to characterize the scope of a shared
metadata for the sake of better interoperability should be
supported.
4.4. Metadata Granularity
The packet requirements mentioned above can be broadly classified
into 2 catagories.
4.4.1. Application Metadata
Application metadata comprise of fields in metadata that specifies
how the application will treat the packet. This information, when
available to the network, can be useful in deciding how to handle
packets during reactive events. This level of granularity cannot be
simply replaced by another bit added to the priority field as
evidenced by the use-case below.
Requirements: Packet information such as REQ-PACKET-RELIABILITY, REQ-
PACKET-NATURE as defined above.
Use-case:
Kaippallimalil, et al. Expires 23 January 2025 [Page 13]
Internet-Draft Network Collaboration Requirements July 2024
1. In an interactive gaming session, the traffic can be of multiple
types such as critical and smoothening glyph updates for graphics
traffic, haptic feedback traffic, audio traffic while the game is
being saved (bulk data). In terms of priority, haptic feedback
gets the highest priority and is often transmitted unreliably,
since getting the feedback late is of minimal use. While
considering only priority levels, during an uneventful session,
haptic feedback would assume highest priority while the
smoothening glyphs get the lower priority along with bulk data.
Although, in a loss-prone network, haptic feedback can be dropped
since it is unreliable while critical glyph and bulk data are
expected to be delivered reliably and can result in
retranmissions if lost. This distinction is not feasible with an
addition to the priority level but can be done by defining more
granular metadata. Information about application's treatment of
the packet is used by the network in deciding how to handle
certain types of packets over the other.
4.4.2. Network Metadata
Network metadata comprise of fields in metadata that specifies how
the network should treat the packet. This dictates how the network
should prioritize the packet and has no bearing on the nature of the
packet itself.
Requirement: Packet handling information such as REQ-PACKET-SELF.
Use-case:
1. In a VoIP session where audio is prioritized over video, both
traffic has the same nature (reliability and interactivity) and
differ only in how the packet needs to be prioritized by the
network to ensure audio reaches more reliably, faster and
coherently than video. This is solely the way application wants
the network to prioritize the packet and not the nature of the
packet itself.
4.5. Multiple Bottlenecks
Whereas models often show a single bottleneck, there are frequently
two (or more) bottlenecks: the ISP network and within the subscriber
network (e.g., Wi-Fi link). As such, all bottlenecks near the
subscriber should be able to benefit from network/host collaboration.
Requirement: REQ-MULTIPLE-BOTTLENECKS should be supported.
Kaippallimalil, et al. Expires 23 January 2025 [Page 14]
Internet-Draft Network Collaboration Requirements July 2024
4.6. Application Interference
Applications that have access to a resource-quota information may
adopt an aggressive behavior (compared to those that don't have
access) if they assumed that a resource-quota like metadata is for
the application, not for the host that runs the applications.
This is challenging for home networks where multiple hosts may be
running behind the same CPE, with each of them running a video
application. The same challenge may apply when tethering is enabled.
Requirement:
REQ-SIGNAL-EXPOSURE-FAIRNESS: Means to expose the signal independent
of the application should be considered. An example of such
exposure is OS APIs.
4.7. Exposure Handling
Signaling to the network (Section 5.1, Section 5.3) and consuming the
signals from the network (Section 5.2) will need to be facilitated by
Application Programming Interfaces (APIs) for any application to use
them. Signaling and retrieval of the signals may not be performed at
a single layer (although not encouraged). Hence, a framework is
required to abstract the underlying protocol(s) and allow the
application(s) to retrieve/send signals using a single or a set of
API(s) independent of the channels that are used to convey the
signals. The API framework is required even if one single channel is
used so that any application can consume the signals.
There might be many channels to signal the metadata such as (non-
exhaustive list):
* Application layer
* TCP options [RFC9293]
* UDP Options [I-D.ietf-tsvwg-udp-options]
* IPv6 Hop-by-Hop Options (Section 4.3 of [RFC8200])
* QUIC CID mapping
* ICMP messages
Requirement:
REQ-API-FRAMEWORK: API framework to facilitate signaling for
Kaippallimalil, et al. Expires 23 January 2025 [Page 15]
Internet-Draft Network Collaboration Requirements July 2024
applications.
4.8. Privacy Considerations
Encrypted media payloads along with temporary IPv6 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 this document and is described here only to provide context
for metadata privacy.
Some metadata (e.g., the size of a burst of packets, sequence number,
and timestamp) can be readily observed or inferred by entities along
the network path. However, it is essential to recognize that while
sequence numbers and timestamps are typically visible in the clear-
text headers of protocols (e.g., TCP, RTP, or SRTP) they are not
directly observable in encrypted protocols such as QUIC. All
metadata sent from the server to the network, including these
elements and others, are vulnerable to modification while in transit.
Only an on-path attacker can modify on-path metadata. Such an
attacker could engage in other malicious activities, like corrupting
the checksum or completely dropping the packet. For instance, an
active attacker could alter the metadata to mislabel packets
containing video key-frames as unimportant, but such changes are
detectable by the receiver.
It is recommended to encrypt or obfuscate the metadata information so
it is only available to hosts and to authorized network elements.
The method of encryption or obfuscation is not described in this
document but rather in other documents describing how this metadata
is encoded and exchanged amongst hosts and network elements. The
privacy implications of revealing metadata to network elements need
to be thoroughly analyzed. This analysis should ensure that any
exposure of metadata does not compromise user privacy or allow
unauthorized entities to infer sensitive information about the data
being transmitted while maintaining minimal resource consumption.
Requirements:
REQ-PRIVACY-ADDITIONAL: An on-path observer obtains no additional
Kaippallimalil, et al. Expires 23 January 2025 [Page 16]
Internet-Draft Network Collaboration Requirements July 2024
information about the IP packet.
REQ-SIGNALING-AVOIDANCE: Leveraging previous experience [RFC9049],
the folliwing is not required to make use of the collaborative
signaling:
* Reveal the application identity.
* Expose the application cause (or 'reason') to signal metadata.
* Reveal server identity.
* Inspect client-to-server encrypted payload by network elements.
4.9. Scalability
There may be a large number of media flows handled by the server and
wireless/access router.
Per flow information (state) at a wireless router for optimizing the
flow can negate the advantages offered as the number of flows handled
increases.
The metadata and other state information that a router has to
maintain for each additional media flow it handles should be kept to
a minimum or eliminated altogether.
Requirement:
REQ-ISP-SCALE: 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.
4.10. Session Continuity
The general trend in wireless networks is to deploy the wireless
router closer to the user. This can help with low link latency but
can result in more frequent handovers as the user moves between
routers. The frequency of handovers increases when a user moves
faster or when the media session lasts longer.
During handovers, there should be minimal delay incurred during
handover in configuring/setting up the metadata of a media session in
progress.
Requirement:
REQ-CONTINUITY: Handover from one radio or router to another should
Kaippallimalil, et al. Expires 23 January 2025 [Page 17]
Internet-Draft Network Collaboration Requirements July 2024
continue to provide same service level.
4.11. Abuse and Constraints
It is important that not every flow be prioritized; otherwise, the
network devolves into the best-effort network that existed prior to
metadata signaling. It is a requirement that mechanisms exist to
prevent this occurrence.
Such a mechanism might be simple, for example, a cellular network
might allow one flow from a subscriber to declare itself as
important; other flows with that subscriber are denied attempts to
prioritize themselves. However, the network cannot identify whether
the prioritized flow is legitimate or malicious.
Requirements:
REQ-SIGNAL-VALIDATION: The network/OS needs to ensure that the user/
client signaling of priority (if any) does not associate the same
priority level with all traffic types within the same flow,
thereby avoiding prioritizing of all the streams/traffic the same
way.
REQ-CLIENT-VALIDATION: The network needs to ensure the signal is
coming from the same user/client that is part of the 5-tuple flow.
This is to ensure no other application influences the priority of
another application's flow.
5. On-path Metadata Requirements
There are various approaches for collaborative signaling between the
server/host and network including out-of-band signaling, client-
centric metadata sharing and proxied connections. The requirements
here focus on proxied metadata connections on path with the data
traffic.
The path signals below should follow the principles of intentional
distribution, protection of information, minimization and limiting
impact as described in [RFC9419] and [RFC8558]. Leveraging previous
experience ([RFC9049]), the metadata signals does not need
application identity, application cause (or 'reason'), server
identity or the inspection of client(host)-to-server encrypted
payload.
The metadata connections may be between server and network (in either
direction) or between host and network (in either direction).
Kaippallimalil, et al. Expires 23 January 2025 [Page 18]
Internet-Draft Network Collaboration Requirements July 2024
Some use cases benefit from server – network metadata exchanges
(Section 5.3) and others need client involvement (Section 5.1).
For the requirements that follow, the assumption is that the client
agrees to the exchange of metadata between the server and network, or
between the client and network.
Requirement:
REQ-PACKET-SELF: Packet importance is indicated by the packet
itself.
Note REQ-PACKET-SELF should meet the requirements of Section 4.8
especially REQ-PRIVACY-ADDITIONAL.
5.1. Host-Network Metadata
5.1.1. Priority between Flows (Inter-flow)
Certain flows being received by a host (or by an application on a
host) are less or more important than other flows of _the same host_.
For example, a host downloading a software update is generally
considered less important than another host doing interactive audio/
video or gaming.
By signaling the relative importance of flows to a network element,
the network element can (de-)prioritize those flows to best
accommodate the needs of the various applications on a same host.
Without a signaling in place between a receiving host and its
network, remote peers are able to mark packets that interfere with
the desires of the receiving host -- making their flows more
important than what the receiving host considers more important.
This eventually causes all flows to be marked as important, or --
more likely -- such priority markings to be ignored.
However, prioritizing between flows, even for the same user/
subscriber, presents the following challenges:
1. Identification and authentication of legitimate applications on
the host. The remote peers can also be malicious and benign.
2. Identifying whether the traffic belongs to a single user or
multiple users from a single network attachment (e.g., tethering
or LAN connected to a CPE). The network will enforce per-
subscriber policies, not per-host.
Kaippallimalil, et al. Expires 23 January 2025 [Page 19]
Internet-Draft Network Collaboration Requirements July 2024
3. Enforcing fairness to all the flows belonging to a single host.
For example, it is a challenge to prevent a platform from marking
certain flows as low priority at platform layer, bypassing the
application, to (de)prioritize certain applications over all the
other applications on the same host. Such unfairness can be
revealed during certification or public benchmark efforts,
though.
Taking into account these challenges, and despite the use case is
described in the document, inter-flow (de)prioritization requirements
are out of the scope of this document.
Future versions of the document may re-consider this conclusion as
a function of the comments received from the TSVWG.
5.1.2. Priority within a Flow (Intra-Flow)
Interactive Audio/Video has long been using [RFC3550] which runs over
UDP. As described in Section 2.3.7.2 of [RFC7478], there is value in
differentiating between voice, video and data. Today's video
streaming is exclusively over TCP but will migrate to QUIC and
eventually is likely to support unreliable transport ([RFC9221],
[I-D.ietf-moq-transport]). With unreliable transport of video in RTP
or QUIC, it is beneficial to differentiate the important video
keyframes from other video frames.
Other applications, as mentioned in Section 3, such as gaming and
remote desktop also benefit from differentiating their packets to the
network.
Many of these flows do not originate from a content provider's
network -- rather, they originate from a peer (e.g., VoIP,
interactive video, peer-to-peer gaming, Remote Desktop, and CDN).
Thus, the flows originate from an IP address that is not known before
connection establishment, so there needs to be a way for the client
to authorize the network elements to receive and hopefully to honor
the metadata of those packets from a remote peer.
Without a signaling in place between a receiving host and its
network, remote peers are able to mark every packet of a flow as
important, causing much the same problem as the previous use case.
Eventually, when all packets of every flow are marked as important,
there is no differentiation between packets within a flow, rendering
the network unable to improve reactive policy decisions.
Requirements: The requirements vary based on use case and user
preference. The requirements listed in Section 3 are applicable
here.
Kaippallimalil, et al. Expires 23 January 2025 [Page 20]
Internet-Draft Network Collaboration Requirements July 2024
5.2. Network-Host Metadata
5.2.1. Assisted Offload
There are cases (crisis) where "normal" network resources cannot be
used at maximum and, thus, a network would seek to reduce or offload
some of the traffic during these events -- often called 'reactive
traffic policy'. An example of such use case is cellular networks
that are overly used (and radio resources exhausted) such as a large
collection of people (e.g., parade, sporting event), or such as a
partial radio network outage (e.g., tower power outage). During such
a condition, an alternative network attachment may be available to
the host (e.g., Wi-Fi).
Network-to-host signals are useful to put in place adequate traffic
distribution policies on the host (e.g., prefer the use of alternate
paths, offload a network) (REQ-NETWORK-SEEKS-LOAD-DOWN).
5.2.2. Network Bandwidth & Network Rate Limiting Policies
Bandwidth constraints exist most predominantly at the access network.
This can be constraints in the network itself or a result of rate
limiting due to various reasons.
Also, traffic exchanged over a network attachment may be subject to
rate-limit policies. These policies may be intentional policies
(e.g., enforced as part of the activation of the network attachment
and typically agreed upon service subscription) or be reactive
policies (e.g., enforced temporarily to manage an overload or during
a DDoS attack mitigation).
Requirements:
REQ-NETWORK-THROUGHPUT: A mechanism to signal the available network
throughput to interested hosts, including changes to throughput.
REQ-NRLP: The network shall inform the host of the Rate limiting
policies
Use cases:
1. Performance Optimization: Some applications support some forms of
bandwidth measurements (e.g., [app-measurement]) which feed how
the content is accessed to using ABR. Complementing or replacing
these measurements with explicit signals will improve overall
network performance and can help optimize the data transfer.
Signaling bandwidth availability allows hosts to avoid
contributing to network congestion.
Kaippallimalil, et al. Expires 23 January 2025 [Page 21]
Internet-Draft Network Collaboration Requirements July 2024
2. Dynamic Adaptation: When the network informs the host about
available bandwidth, the host can dynamically adjust its data
transmission rate.
3. Efficient Resource Utilization: Knowing available bandwidth helps
the host allocate resources efficiently.
4. Auto-Scaling Applications: Cloud-based applications can auto-
scale based on available bandwidth.
5. Rate Limiting: Monthly data quotas on cellular networks can be
easily exceeded by video streaming, in particular, if the client
chooses excessively high quality or routinely abandons watching
videos that were downloaded. The network can assist the client
by informing the client of the network's bandwidth policy.
5.3. Server-Network Metadata
5.3.1. Identification of Media Frames and Streams
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 or streams
and adapt to changes in coding due to dynamic content or resulting
from network conditions.
Relative priority and tolerance to delay of media frames or streams
can be used to optimize traffic shaping at the wireless router. The
application can provide information to detect the start, end and set
of packets that belong to a media frame. Alternatively, the
application may provide information to identify one stream of the
flow from another. The application provides information to identify
either media frames or streams in a flow but not both.
In cases where the wireless network has to drop or delay processing,
all packets of the media frame or stream are treated in the same
manner.
Requirements:
REQ-FRAME-ASSOCIATED: Identify all packets belonging to the same
media frame, so they can receive equal drop/forward treatment.
Kaippallimalil, et al. Expires 23 January 2025 [Page 22]
Internet-Draft Network Collaboration Requirements July 2024
5.3.2. Identification of Traffic Type without Disclosure of the
Application
Different nature/types of traffic can be part of the same 5-tuple
flow. This could be reliable/loss-tolerant [RFC9221], bulk/
interactive traffic. The type of traffic can be used to prioritize/
buffer packets as needed and deprioritize/discard appropriate packets
during reactive events, thereby optimizing performance. The
application may provide information to identify the type of traffic
in per-packet metadata.
Requirements: REQ-PACKET-RELIABILITY, REQ-PACKET-NATURE as defined in
Section 3.5.
5.3.3. Relative Priority
Relative importance of a media frame provides the priority level of
one media frame over another media frame within 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 of a media frame in cases of extreme
congestion in the wireless network.
Relative importance of a media stream is the priority level of one
media stream over another stream in the flow (with the same IP
5-tuple). As with media frames, importance may be used to determine
drop priority in cases of extreme congestion in the wireless network.
There is no requirement associated with this use case.
5.3.4. Tolerance to Delay
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). Similarly, some media streams can tolerate more
delay over the wire than others (e.g., a stream carrying a background
image may tolerate more delay). ams 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.
If the application can indicate that a media frame or stream can
tolerate high delay the wireless router can opt to delay packets
rather than drop during transient congestion periods.
Kaippallimalil, et al. Expires 23 January 2025 [Page 23]
Internet-Draft Network Collaboration Requirements July 2024
Requirements:
REQ-DELAY-TOLERANCE: REQ-PACKET-RELIABILITY, REQ-PACKET-NATURE as
defined in Section 3.5.
5.3.5. Burst Indication
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 allowed as that
will likely lead to poor utilization of radio resources or tail
drops.
The server may provide burst size at the beginning of the burst to
allow the scheduler to reserve sufficient resources (and avoid having
too few resources that may lead to a tail drop). The server may also
signal end of burst that provides information for the radio to go
into sleep mode (Connected Mode Discontinuous Reception, C-DRX) if
there is no paging message.
REQ-BURST-INDICATOR: Client indicates this flow's maximum burst to
the service provider network, and network agrees it can handle
that burst size.
6. Non-Requirements
Application feedback with measurements of packets lost and delay
incurred may affect the sending rate and other behavior of the
application. The requirements and specification to mitigate these
aspects are not in the scope of this document.
7. IANA Considerations
None.
8. Security Considerations
Security aspects for the metadata are discussed in Section 4.8. The
principles outlined in [RFC8558], [RFC9049] and [RFC9419] contain
security considerations and are referenced in Section 5.
This document has no other security considerations.
Kaippallimalil, et al. Expires 23 January 2025 [Page 24]
Internet-Draft Network Collaboration Requirements July 2024
Acknowledgments
This document is a merge of [I-D.rwbr-tsvwg-signaling-use-cases] and
[I-D.kaippallimalil-tsvwg-media-hdr-wireless].
T. Reddy contributed text and ideas to this document.
Acknowledgments from
[I-D.kaippallimalil-tsvwg-media-hdr-wireless]: 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.
Ingemar Johansson's suggestions on fast fading (which L4S handles)
and dramatic drops in wireless accesses have been helpful to
identify the issues. Thanks to Hang Shi for the review and
comments on host-to-network signaling. Thanks to Luis Miguel
Contreras and Colin Kahn for their review and comments.
Informative References
[app-measurement]
Gurel, Z. and A. C. Begen, "Bandwidth measurement for
QUIC", 2024, <https://datatracker.ietf.org/doc/slides-119-
moq-bandwidth-measurement-for-quic/>.
[I-D.ietf-moq-transport]
Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and
I. Swett, "Media over QUIC Transport", Work in Progress,
Internet-Draft, draft-ietf-moq-transport-05, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-moq-
transport-05>.
[I-D.ietf-opsawg-teas-attachment-circuit]
Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S.,
and B. Wu, "YANG Data Models for Bearers and 'Attachment
Circuits'-as-a-Service (ACaaS)", Work in Progress,
Kaippallimalil, et al. Expires 23 January 2025 [Page 25]
Internet-Draft Network Collaboration Requirements July 2024
Internet-Draft, draft-ietf-opsawg-teas-attachment-circuit-
13, 29 May 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-opsawg-teas-attachment-circuit-13>.
[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>.
[I-D.kaippallimalil-tsvwg-media-hdr-wireless]
Kaippallimalil, J., Gundavelli, S., and S. Dawkins, "Media
Handling Considerations for Wireless Networks", Work in
Progress, Internet-Draft, draft-kaippallimalil-tsvwg-
media-hdr-wireless-04, 14 February 2024,
<https://datatracker.ietf.org/doc/html/draft-
kaippallimalil-tsvwg-media-hdr-wireless-04>.
[I-D.rwbr-tsvwg-signaling-use-cases]
Rajagopalan, S., Wing, D., Boucadair, M., and T. Reddy.K,
"Host to Network Signaling Use Cases for Collaborative
Traffic Differentiation", Work in Progress, Internet-
Draft, draft-rwbr-tsvwg-signaling-use-cases-02, 17 March
2024, <https://datatracker.ietf.org/doc/html/draft-rwbr-
tsvwg-signaling-use-cases-02>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/rfc/rfc3550>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, DOI 10.17487/RFC3662, December 2003,
<https://www.rfc-editor.org/rfc/rfc3662>.
[RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B.
Briscoe, "Open Research Issues in Internet Congestion
Control", RFC 6077, DOI 10.17487/RFC6077, February 2011,
<https://www.rfc-editor.org/rfc/rfc6077>.
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use Cases and Requirements", RFC 7478,
DOI 10.17487/RFC7478, March 2015,
<https://www.rfc-editor.org/rfc/rfc7478>.
Kaippallimalil, et al. Expires 23 January 2025 [Page 26]
Internet-Draft Network Collaboration Requirements July 2024
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",
RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/rfc/rfc8558>.
[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for
Browser-Based Applications", RFC 8825,
DOI 10.17487/RFC8825, January 2021,
<https://www.rfc-editor.org/rfc/rfc8825>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to
Deployment (A Bestiary of Roads Not Taken)", RFC 9049,
DOI 10.17487/RFC9049, June 2021,
<https://www.rfc-editor.org/rfc/rfc9049>.
[RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
Datagram Extension to QUIC", RFC 9221,
DOI 10.17487/RFC9221, March 2022,
<https://www.rfc-editor.org/rfc/rfc9221>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/rfc/rfc9293>.
[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>.
[RFC9419] Arkko, J., Hardie, T., Pauly, T., and M. Kühlewind,
"Considerations on Application - Network Collaboration
Using Path Signals", RFC 9419, DOI 10.17487/RFC9419, July
2023, <https://www.rfc-editor.org/rfc/rfc9419>.
[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.
Kaippallimalil, et al. Expires 23 January 2025 [Page 27]
Internet-Draft Network Collaboration Requirements July 2024
[TR.23.700-60-3GPP]
"Study on XR (Extended Reality) and media services
(Release 18)", August 2022.
[_5G-Lumos]
"Lumos5G: Mapping and Predicting Commercial mmWave 5G
Throughput, Arvind Narayanan et al., ACM Internet
Measurement Conference (IMC '20),
https://dl.acm.org/doi/10.1145/3419394.3423629", October
2020.
Authors' Addresses
John Kaippallimalil
Futurewei
Email: john.kaippallimalil@futurewei.com
Dan Wing
Cloud Software Group Holdings, Inc.
Email: danwing@gmail.com
Sri Gundavelli
Cisco
Email: sgundave@cisco.com
Sridharan Rajagopalan
Cloud Software Group Holdings, Inc.
Email: Sridharan.girish@gmail.com
Spencer Dawkins
Tencent America LLC
Email: spencerdawkins.ietf@gmail.com
Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
Kaippallimalil, et al. Expires 23 January 2025 [Page 28]