Internet DRAFT - draft-rwbr-tsvwg-signaling-use-cases
draft-rwbr-tsvwg-signaling-use-cases
Transport and Services Working Group S. Rajagopalan
Internet-Draft D. Wing
Intended status: Informational Cloud Software Group
Expires: 5 September 2024 M. Boucadair
Orange
T. Reddy
Nokia
4 March 2024
Signaling Use Cases for Collaborative Traffic Differentiation
draft-rwbr-tsvwg-signaling-use-cases-01
Abstract
Host-to-network (and vice versa) signaling can improve the user
experience by informing the network which flows are more important
and which packets within a flow are more important without having to
disclose the content of the packets being delivered. The
differentiated service may be provided at the network (e.g., packet
discard preference), the sender (e.g., adaptive transmission or
session migration), or through cooperation of both the host and the
network.
This document outlines a set of use-cases that highlight the need for
a mechanism to share metadata about flows between a host and its
network in order to enable different traffic treatment. Such a
mechanism is typically implemented using a signaling protocol between
the host and a set of trusted netwrok elements.
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://danwing.github.io/signaling-use-cases/draft-wing-tsvwg-
signaling-use-cases.html. Status information for this document may
be found at https://datatracker.ietf.org/doc/draft-rwbr-tsvwg-
signaling-use-cases/.
Discussion of this document takes place on the Transport and Services
Working Group 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/.
Source for this draft and an issue tracker can be found at
https://github.com/danwing/signaling-use-cases.
Rajagopalan, et al. Expires 5 September 2024 [Page 1]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
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 5 September 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. Scope & Running Experiments . . . . . . . . . . . . . . . . . 5
3. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
4. Various Approaches for Collaborative Signaling . . . . . . . 5
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Generic Cases . . . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Priority Between Flows (Inter-Flow) of The Same
Host . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.2. Priority Within a Flow (Intra-Flow) . . . . . . . . . 7
5.2. Detailed Use Cases . . . . . . . . . . . . . . . . . . . 7
5.2.1. Video Streaming . . . . . . . . . . . . . . . . . . . 7
5.2.2. Interactive Media . . . . . . . . . . . . . . . . . . 8
5.2.3. Bulk Data Transfer . . . . . . . . . . . . . . . . . 10
5.2.4. Mixed Traffic . . . . . . . . . . . . . . . . . . . . 10
5.2.5. Assisted Offload . . . . . . . . . . . . . . . . . . 16
Rajagopalan, et al. Expires 5 September 2024 [Page 2]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
6. Operational Considerations . . . . . . . . . . . . . . . . . 16
6.1. Abuse and Constraints . . . . . . . . . . . . . . . . . . 16
6.2. Key Establishment . . . . . . . . . . . . . . . . . . . . 17
6.3. Metadata Version/Capability Exchange . . . . . . . . . . 17
6.4. On the Use of Fast Path . . . . . . . . . . . . . . . . . 17
6.5. Impacts of Nested Congestion Controls . . . . . . . . . . 17
7. Requirements Summary . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Informative References . . . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
Bandwidth constraints exist most predominantly at the access network
(e.g., radio access networks). Users who are serviced via these
networks use various hosts which run various applications; 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).
The simple network diagram below shows where such bandwidth and
performance constraints usually exist with a "B" (for Bottleneck).
Other network bottlenecks may be experienced in other segments not
shown in the figure, such as interconnection links or the
infrastructure that hosts the service (e.g., flash crowds). A
bottleneck may be limited in time, present or not regular patters,
etc.
+------+ | | |
+----+ |WLAN | | +------+ +------+ | +------+ | +----+
|host+--B--+access+--B--+router+--+router+---+router+---+host|
+----+ |point | | +------+ +------+ | +------+ | +----+
+------+ | | |
| | Transit | Content
User Network | ISP Network | Network | Network
Complications that are induced by such phenomena may be eliminated by
adequate dimensioning and upgrades. However, such upgrades may not
be always immediately possible or economically justified.
Complementary mitigations are thus needed to soften these
complications by introducing some collaboration between hosts and
networks to adjust their behaviors.
Rajagopalan, et al. Expires 5 September 2024 [Page 3]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
For traffic sent in either direction, the network network elements
that terminate a bandwidth constraining link (or located few hops
next to that element) can be fed with flow metadata. Such
augmentation allows those network elements to make autonomous
decisions to prioritize, delay, or drop packets, especially when
performing reactive resource management. Absent such metadata, these
network elements have no means to guide the enforcement of the
reactive resource policy.
There are several challenges with this metadata augmentation:
* for hosts: which data to share without privacy breach or lowering
confidentiality.
* for network elements:
- Deciding which metadata to trust
- Tradeoff between the extra cost (including processing) vs.
expected benefits
- Impact on the network operations
The metadata signals from a content provider are more likely to be
authentic (if adequate authorization/validation are in place) but the
metadata signals from other hosts may be "wrong", undesired by the
peer host, or maliciously contain improper metadata. Attempts to
automate identification of content providers have included HTTP
"Host" header inspection and TLS SNI inspection which are expected to
fail as encrypted SNI and privacy-enhancing proxies become more
prevalent. Another mechanism to authorize metadata signals from a
content provider is to configure the ISP equipment with the content
network's source IP addresses (or other labels that may be visible on
the packets) and provide a differentiated service to the traffic that
match these criteria. However, such an arrangement may have
scalability issues. An approach to mitigate these issues is to limit
the target contents networks and networks that would put in place
these arrangements. Such limitations would benefit large players
(large ISPs and large content network) and disadvantages small
players (and new players). A more egalitarian approach would provide
the same benefit to all parties -- large and small -- and also
provide richer signaling to further improve user experience and
metadata interoperability. This would allow all parties to become
part of the "Internet fast lane".
The authorization problem exists with technologies as relatively
simple as DiffServ and the problem persists with many other recently
discussed metadata signaling mechanisms, including embedding
Rajagopalan, et al. Expires 5 September 2024 [Page 4]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
information in the UDP payload ([I-D.trammell-plus-spec]), UDP
options ([I-D.kaippallimalil-tsvwg-media-hdr-wireless]), overloading
the IPv6 Flow Label ([I-D.cc-v6ops-wlcg-flow-label-marking], and Hop-
by-Hop Options. One mechanism suggested occasionally is to encrypt
or integrity protect the metadata with a key; such a key could be
established using a signaling protocol, see Section 6.2.
There is some consensus that applications can benefit by
collaborative signaling the network ([IAB], [ATIS]). This document
provides use-cases to further detail the need of such signaling.
2. Scope & Running Experiments
This document does not intend to define any signaling protocol nor
call whether a new signaling protocol, a new extension, one or more
signaling protocols are needed.
However, this document provides a reference to digest the intended
benefits for enabling collaborating between hosts and networks.
These benefits are yet to be backed up with more evidence. Some
experimental work would be reasonable to be endorsed by the IETF to
solicit more feedback and collect assess the benefits under various
setups.
3. Conventions and Definitions
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, with
very short to very long durations (e.g., varying wireless and
mobile air interface conditions).
4. Various Approaches for Collaborative Signaling
Figure 1 depicts examples of approaches to establish channels to
convey and share metadata between hosts, networks, and servers.
Metadata exchanges can occur in one single direction or both
directions of a flows.
Rajagopalan, et al. Expires 5 September 2024 [Page 5]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
(1) Proxied Connection
.--------------. +------+
| | +-+----+ |
+------+ | Network(s) | +-+----+ +-+
|Client+--------------)----------------(--------------+Server+-+
+---+--+ | | +---+--+
| '-------+------' |
| | |
+<===User Data+Metadata===>+<===User Data+Metadata===>+
| Secure Connection 1 | Secure Connection 2 |
| | |
(2) Out-of-band Metadata Sharing
.--------------. +------+
| | +-+----+ |
+------+ | Network(s) | +-+----+ +-+
|Client+---------------)----------------(-------------+Server+-+
+---+--+ | | +---+--+
| '-------+------' |
| | |
+<-----End-to-End Secure Connection + User Data------>+<---.
| | | GLUE|
| | | CXs |
+<-- Metadata (Optional) -->+<----- Metadata -------->+<---'
| Secure Connection 1 | Secure Connection 2 |
| | |
(3) Client-centric Metadata Sharing
.--------------. +------+
| | +-+----+ |
+------+ | Network(s) | +-+----+ +-+
|Client+-----------------)----------------(-------------+Server+-+
+---+--+ | | +---+--+
| '-------+------' |
| | |
+<--------- Metadata -------->+ |
| Secure Connection | |
| | |
+<== End-to-End Secure Connection User Data+Metadata ==>+
| | |
Figure 1: Candidate Signaling Approaches
The client-centric metadata sharing approach because it preserves
privacy and also takes advantage of clients having a full view on
their available network attachments.
Rajagopalan, et al. Expires 5 September 2024 [Page 6]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
5. Use Cases
5.1. Generic Cases
5.1.1. Priority Between Flows (Inter-Flow) of The Same Host
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 accomodate the needs of the various applications (on a same
host) and between hosts on a network.
5.1.2. Priority Within a Flow (Intra-Flow)
Interactive Audio/Video has long been using [RTP] 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.kpugin-rush]). With unreliable transport of video in RTP or
QUIC, it is beneficial to differentiate the important video keyframes
from other video frames. Other applications 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. 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.
5.2. Detailed Use Cases
5.2.1. Video Streaming
Streaming video contains the occasional key frame ("i-frame")
containing a full video frame. These 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. Audio is more
critical than video for almost all applications, but its importance
(relative to other packets in the flow) is still an application
decision. In the example below, the audio is more important than
Rajagopalan, et al. Expires 5 September 2024 [Page 7]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
video (importance=high, PT=keep, RU=reliable), video key frames have
middle importance (importance=low, PT=discard, RU=reliable), and both
types of video delta frames (P-frame and B-frame) have least
importance (importance=low, PT=discard, RU=unreliable).
Video Streaming Metadata:
Based on metadata types listed in the
[I-D.rwbr-sconepro-flow-metadata], the host to network metadata
parameters for video streaming type is given below.
+===============+============+==============+============+
| Traffic type | Importance | PacketNature | PacketType |
+===============+============+==============+============+
| video I-frame | low | realtime | reliable |
| (key frame) | | | |
+---------------+------------+--------------+------------+
| video delta | low | discard | unreliable |
| P-frame | | | |
+---------------+------------+--------------+------------+
| video delta | low | discard | unreliable |
| B-frame | | | |
+---------------+------------+--------------+------------+
| audio | high | realtime | reliable |
+---------------+------------+--------------+------------+
Table 1: Example Values for Video Streaming Metadata
5.2.2. Interactive Media
Examples: VoIP, gaming.
Requirement: Signal the flow needs low jitter and low delay.
However, the network can only provide a limited amount of low jitter/
low delay to each host, maybe as few as one. This requires signaling
feedback indicating that low jitter and low delay flows are already
subscribed to other hosts. In response, the user and the application
will likely continue, occasionally re-attempting to get the desired
quality of service from the network.
In many scenarios a game or VoIP application will 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.
Rajagopalan, et al. Expires 5 September 2024 [Page 8]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
Both gaming (video in both directions, audio in both directions,
input devices from client to server) and interactive audio/video
(VoIP, video conference) involves important traffic in both
directions -- thus is a slightly more complicated use-case than the
previous example. Additionally, most Internet service providers
constrain upstream bandwidth so proper packet treatment is critical
in the upstream direction.
Metadata:
Based on metadata types listed in the
[I-D.rwbr-sconepro-flow-metadata], the host to network metadata
parameters for interactive media type is given below.
Interactive A/V, downstream Metadata:
+===================+============+==============+============+
| Traffic type | Importance | PacketNature | PacketType |
+===================+============+==============+============+
| video key frame | low | realtime | reliable |
+-------------------+------------+--------------+------------+
| video delta frame | low | discard | unreliable |
+-------------------+------------+--------------+------------+
| audio | high | realtime | reliable |
+-------------------+------------+--------------+------------+
Table 2: Example Values for Interactive A/V, downstream
+===================+============+==============+============+
| Traffic type | Importance | PacketNature | PacketType |
+===================+============+==============+============+
| video key frame | low | realtime | reliable |
+-------------------+------------+--------------+------------+
| video delta frame | low | discard | unreliable |
+-------------------+------------+--------------+------------+
| audio | high | realtime | reliable |
+-------------------+------------+--------------+------------+
Table 3: Example Values for Interactive A/V, upstream
Many interactive audio/video applications also support sharing the
presenter's screen, file, video, or pictures. During this sharing
the presenter's video is less important but the screen or picture is
more important. This change of imporance can be conveyed in metadata
to the network, as in the table below:
Interactive A/V, upstream Metadata:
Rajagopalan, et al. Expires 5 September 2024 [Page 9]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
+===================+============+==============+============+
| Traffic type | Importance | PacketNature | PacketType |
+===================+============+==============+============+
| video key frame | low | realtime | reliable |
+-------------------+------------+--------------+------------+
| video delta frame | low | discard | unreliable |
+-------------------+------------+--------------+------------+
| audio | high | realtime | reliable |
+-------------------+------------+--------------+------------+
| picture sharing | high | realtime | reliable |
+-------------------+------------+--------------+------------+
Table 4: Example Values for Interactive A/V with picture
sharing, upstream
In many scenarios a game or VoIP application will 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.
Todo: this section on cooperation needs editing.
5.2.3. Bulk Data Transfer
Examples: backup/restore, software update, RSS feed update, email,
printing to a print server
Requirement: Signal the flow as below best-effort.
Metadata:
+==============+============+==============+============+==========+
| Traffic type | Importance | PacketNature | PacketType | Comments |
+==============+============+==============+============+==========+
| File copy | low | bulk | reliable | |
+--------------+------------+--------------+------------+----------+
| Printing | high | bulk | reliable | |
+--------------+------------+--------------+------------+----------+
Table 5
5.2.4. Mixed Traffic
Examples: Desktop Virtualization, Office software in the cloud
(editing local files, typing is interactive while save operation is
bulk transfer)
Rajagopalan, et al. Expires 5 September 2024 [Page 10]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
Requirement: Signal flow will vary depending on the nature of the
packet. With variety of traffic going through the session, some
packets can contain interactive traffic while the others contain bulk
transfer. There can be combination of reliable and unreliable
traffic within the same session through multiple streams. Host-to-
network signaling plays a vital role in effectively routing mixed
traffic for ideal user interactivity and network performance.
Example packet metadata for Desktop Virtualization (like Citrix
Virtual Apps and Desktops - CVAD) application. This is shown in two
tables, client-to-server traffic (Table 6) and server-to-client
traffic (Table 7).
Remote Desktop Virtualization Metadata:
Based on metadata types listed in the
[I-D.rwbr-sconepro-flow-metadata], the host to network metadata
parameters for remote desktop virtualization type is given below.
+================+==========+==============+==========+=============+
| Traffic type |Importance| PacketNature |PacketType| Comments |
+================+==========+==============+==========+=============+
| User typing | high | realtime | reliable | |
+----------------+----------+--------------+----------+-------------+
| Mouse click/ | high | realtime | reliable | The start |
| End Position | | | | and endpoint|
| | | | | of the |
| | | | | pointer |
| | | | | movement is |
| | | | | vital to |
| | | | | ensure user |
| | | | | action is |
| | | | | completed |
| | | | | correctly. |
| | | | | So, the |
| | | | | endpoints |
| | | | | have to be |
| | | | | reliably |
| | | | | transmitted |
| | | | | with real- |
| | | | | time |
| | | | | priority. **|
+----------------+----------+--------------+----------+-------------+
| Interactive | high | keep |unreliable| |
| audio | | | | |
+----------------+----------+--------------+----------+-------------+
| Authentication | low | realtime | reliable | |
| - Finger | | | | |
Rajagopalan, et al. Expires 5 September 2024 [Page 11]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
| print, smart | | | | |
| card | | | | |
+----------------+----------+--------------+----------+-------------+
| Interactive | low | keep |unreliable| Video key |
| video key | | | | frames form |
| frame | | | | the base |
| | | | | frames of a |
| | | | | video upon |
| | | | | which the |
| | | | | next 'n' |
| | | | | timeframe of|
| | | | | video |
| | | | | updates is |
| | | | | applied on. |
| | | | | These |
| | | | | frames, are |
| | | | | hence, |
| | | | | critical and|
| | | | | without |
| | | | | them, the |
| | | | | video would |
| | | | | not be |
| | | | | coherent |
| | | | | until the |
| | | | | next |
| | | | | critical |
| | | | | frame is |
| | | | | received. |
| | | | | Retransmits |
| | | | | of these are|
| | | | | harmful to |
| | | | | the UX. *** |
+----------------+----------+--------------+----------+-------------+
| Mouse position | low | discard |unreliable| When the |
| tracking | | | | pointer is |
| | | | | moved from |
| | | | | one point to|
| | | | | another, the|
| | | | | coordinates |
| | | | | of the |
| | | | | pointers |
| | | | | between the |
| | | | | two points |
| | | | | can be lost |
| | | | | without much|
| | | | | of an impact|
| | | | | to the UX as|
| | | | | long as the |
Rajagopalan, et al. Expires 5 September 2024 [Page 12]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
| | | | | start and |
| | | | | endpoint |
| | | | | reaches. |
| | | | | This would |
| | | | | ensure the |
| | | | | user action |
| | | | | is |
| | | | | completed, |
| | | | | even if the |
| | | | | experience |
| | | | | seems |
| | | | | glitchy. |
+----------------+----------+--------------+----------+-------------+
| Interactive | low | discard |unreliable| |
| video delta | | | | |
| frame | | | | |
+----------------+----------+--------------+----------+-------------+
Table 6: Example Values for Remote Desktop Virtualization
Metadata, client to server
+===========+==========+==============+==========+==================+
| Traffic |Importance| PacketNature |PacketType| Comments |
| type | | | | |
+===========+==========+==============+==========+==================+
| Glyph | high | realtime | reliable | The frames that |
| critical | | | | form the base |
| | | | | for the image |
| | | | | is more |
| | | | | critical and |
| | | | | needs to be |
| | | | | transmitted as |
| | | | | reliably as |
| | | | | possible. |
| | | | | Retransmits of |
| | | | | these are |
| | | | | harmful to the |
| | | | | UX.** |
+-----------+----------+--------------+----------+------------------+
|Interactive| high | keep |unreliable| |
| (or | | | | |
| streaming)| | | | |
| audio | | | | |
+-----------+----------+--------------+----------+------------------+
| Haptic | high | discard |unreliable| Virtualizing |
| feedback | | | | haptic feedback |
| | | | | is real-time |
| | | | | and high |
Rajagopalan, et al. Expires 5 September 2024 [Page 13]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
| | | | | importance |
| | | | | although the |
| | | | | feedback being |
| | | | | delivered late |
| | | | | is of no use. |
| | | | | So dropping the |
| | | | | packet |
| | | | | altogether and |
| | | | | not |
| | | | | retransmitting |
| | | | | it makes more |
| | | | | sense |
+-----------+----------+--------------+----------+------------------+
|Interactive| low | keep |unreliable| Video key |
| (or | | | | frames form the |
| streaming)| | | | base frames of |
| video key | | | | a video upon |
| frame | | | | which the next |
| | | | | 'n' timeframe |
| | | | | of video |
| | | | | updates is |
| | | | | applied on. |
| | | | | These frames, |
| | | | | are hence, |
| | | | | critical and |
| | | | | without them, |
| | | | | the video would |
| | | | | not be coherent |
| | | | | until the next |
| | | | | critical frame |
| | | | | is received. |
| | | | | Retransmits of |
| | | | | these are |
| | | | | harmful to the |
| | | | | UX. *** |
+-----------+----------+--------------+----------+------------------+
| File copy | low | bulk | reliable | |
+-----------+----------+--------------+----------+------------------+
|Interactive| low | discard |unreliable| Video |
| (or | | | | predictive |
| streaming)| | | | frames can be |
| video | | | | lost, which |
| predictive| | | | would result in |
| frame | | | | minor glitch |
| | | | | but not |
| | | | | compromise the |
| | | | | user activity |
| | | | | and video would |
Rajagopalan, et al. Expires 5 September 2024 [Page 14]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
| | | | | still be |
| | | | | coherent and |
| | | | | useful. The |
| | | | | reception of |
| | | | | subsequent |
| | | | | video key frame |
| | | | | would mitigate |
| | | | | the loss in |
| | | | | quality caused |
| | | | | by lost |
| | | | | predictive |
| | | | | frames. |
+-----------+----------+--------------+----------+------------------+
| Glyph | low | discard |Unreliable| The smoothing |
| smoothing | | | | elements of the |
| | | | | glyph can be |
| | | | | lost and would |
| | | | | still present a |
| | | | | recognizable |
| | | | | image, although |
| | | | | with a lesser |
| | | | | quality. |
| | | | | Hence, these |
| | | | | can be marked |
| | | | | as loss |
| | | | | tolerant as the |
| | | | | user action is |
| | | | | still completed |
| | | | | with a small |
| | | | | compromise to |
| | | | | the UX. |
| | | | | Moreover, with |
| | | | | the reception |
| | | | | of the next |
| | | | | glyph critical |
| | | | | frame would |
| | | | | mitigate the |
| | | | | loss in quality |
| | | | | caused by lost |
| | | | | glyph smoothing |
| | | | | elements. |
+-----------+----------+--------------+----------+------------------+
Table 7: Example Values for Remote Desktop Virtualization
Metadata, server to client
Rajagopalan, et al. Expires 5 September 2024 [Page 15]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
*** A video key frame should be handled differently by the network
depending on a streaming application versus a remote desktop
application. The video streaming application's primary and only
nature of traffic is video and audio. In contrast, a remote desktop
application might be playing a video and its associated audio while
at the same time the user is editing a document. The user's
keystrokes and those glyphs need to be prioritized over the video
lest the user think their inputs are being ignored (and type the same
characters again). Hence, the values are different even for the same
nature of traffic but a different application.
5.2.5. 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 sue case is cellular networks
that are overly used (and radio resources exhausted) while
alternative network attachment networks are available to host.
Network-to-host signals are useful to put in place adequate traffic
distribution policies (e.g., prefer the use of alternate paths,
offload a network).
6. Operational Considerations
6.1. 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. The mechanism might be more complex where
authentication and authorization is performed by an enterprise
network which, itself, decides which flows are important based on its
policy and only the enterprise network communicates flow priorities
to the ISP network. The enterprise might prioritize certain users
(e.g., IT staff), certain equipment (audio/video equipment in a
conference room), or whatever its policies it might want.
Rajagopalan, et al. Expires 5 September 2024 [Page 16]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
6.2. Key Establishment
Various proposals have suggested establishing a key to validate per-
packet metadata or to decrypt per-packet metadata. However, most
proposals have not specified how this key would be established. A
signaling protocol from the receiving host to its ISP could establish
such a key. The host can then convey the key to the sending host to
use to integrity protect or encrypt the per-packet metadata.
Note: The CPU overhead of validating or decrypting such per-packet
metadata needs to be carefully considered (and further assessed
via experiments) by the signaling protocol proposing such keying.
Also, the required operational setup should be documented.
6.3. Metadata Version/Capability Exchange
The sender has to convey metadata in a way that is understood by the
various network elements on the path -- each of which might be
operated by different entities and have different capabilities. For
example, the Wi-Fi access point might be operated by an enterprise
network, hotel, or home user, whereas the upstream router is operated
by the ISP. Each of those might support different versions of the
same metadata, or might need the metadata expressed in different
ways.
The signaling protocol would provide a way to learn the needs of
those networks, and provide metadata signaling satisfying most or all
of their needs.
6.4. On the Use of Fast Path
TBC
6.5. Impacts of Nested Congestion Controls
TBC
7. Requirements Summary
TODO summary.
8. Security Considerations
TODO Security
Rajagopalan, et al. Expires 5 September 2024 [Page 17]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
9. IANA Considerations
This document has no IANA actions.
10. Informative References
[ATIS] "Content Classification for Traffic Optimization", 2023,
<https://access.atis.org/higherlogic/ws/public/
download/72240>.
[I-D.cc-v6ops-wlcg-flow-label-marking]
Carder, D. W., Chown, T., McKee, S., and M. Babik, "Use of
the IPv6 Flow Label for WLCG Packet Marking", Work in
Progress, Internet-Draft, draft-cc-v6ops-wlcg-flow-label-
marking-02, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-cc-v6ops-
wlcg-flow-label-marking-02>.
[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.kpugin-rush]
Pugin, K., Frindell, A., Ferret, J. C., and J. Weissman,
"RUSH - Reliable (unreliable) streaming protocol", Work in
Progress, Internet-Draft, draft-kpugin-rush-02, 10 May
2023, <https://datatracker.ietf.org/doc/html/draft-kpugin-
rush-02>.
[I-D.rwbr-sconepro-flow-metadata]
Rajagopalan, S., Wing, D., Boucadair, M., and T. Reddy.K,
"Flow Metadata for Collaborative Host/Network Signaling",
Work in Progress, Internet-Draft, draft-rwbr-sconepro-
flow-metadata-00, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-rwbr-
sconepro-flow-metadata-00>.
[I-D.trammell-plus-spec]
Trammell, B. and M. Kühlewind, "Path Layer UDP Substrate
Specification", Work in Progress, Internet-Draft, draft-
trammell-plus-spec-01, 13 March 2017,
<https://datatracker.ietf.org/doc/html/draft-trammell-
plus-spec-01>.
Rajagopalan, et al. Expires 5 September 2024 [Page 18]
Internet-Draft Collaborative Host/Network Signaling: Us March 2024
[IAB] 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>.
[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>.
[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>.
[RTP] 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>.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Sridharan Rajagopalan
Cloud Software Group Holdings, Inc.
United States of America
Email: sridharan.girish@gmail.com
Dan Wing
Cloud Software Group Holdings, Inc.
United States of America
Email: danwing@gmail.com
Mohamed Boucadair
Orange
France
Email: mohamed.boucadair@orange.com
Tirumaleswar Reddy
Nokia
India
Email: kondtir@gmail.com
Rajagopalan, et al. Expires 5 September 2024 [Page 19]
