Host to Network Signaling Use Cases for Collaborative Traffic Differentiation

Host to Network Signaling Use Cases for Collaborative Traffic Differentiation Cloud Software Group Holdings, Inc.

United States of America sridharan.girish@gmail.com

Cloud Software Group Holdings, Inc.

United States of America danwing@gmail.com

Orange

France mohamed.boucadair@orange.com

Nokia

India kondtir@gmail.com

Web and Internet Transport Transport and Services Working Group user experience bandwidth priority enriched feedback media streaming realtime media QoS 5G Wi-Fi WiFi diffserv 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 lists use cases demonstrating the need for a mechanism to share metadata about flows between a receiving host and its networks to enable differentiated traffic treatment for packets sent to the host. Such a mechanism is typically implemented using a signaling protocol between the host and a set of network elements. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Transport and Services Working Group Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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). 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'. 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 a host and its networks to adjust their behaviors. 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 guidance and treat packets indiscriminately. There are several challenges with this metadata augmentation:

for hosts:
- which data to share without privacy breach or lowering confidentiality.
for network elements:
- Which metadata to honor
- Tradeoff between the extra cost (including processing) versus benefits
- Operational impacts

Configured cooperation between an ISP and content providers (via contractual agreements, typically) can allows metadata signals augmenting packets to be honored by the ISP. This cooperation has historically involved examination of server IP address, TLS SNI, AS number, or heuristics to identify flows. However, this cooperation might have scalability issues (e.g., ISPs to establish and maintain agreements with a large number of content providers), operational implications as the network configuration will rely on service-specific (e.g., risk of frozen or stale configuration), mismatch between the expected service level from users and the delivered one, etc. Moreover, smaller ISPs, small content providers, and new content providers are harmed. A more egalitarian approach provides the same benefit to parties -- large and small -- and also provide richer signaling to further improve user experience and metadata interoperability. This allows all parties, big and small, to request the network differentiate a flow, improving the Internet for end users per . Rather than relying on configured cooperation between ISPs and content providers, this document shows use cases where the client tells its ISP the importance of packets it is receiving. This provides several benefits described in later sections. There is already some consensus that applications can benefit by collaborative signaling the network (, ). This document provides use cases to further detail the need of such signaling and highlights the value of the receiving host signaling to its network about flows being sent to the host.

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 of a host and its 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.

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).

Various Approaches for Collaborative Signaling depicts examples of approaches to establish channels to convey and share metadata between a host, its networks, and the servers. Metadata exchanges can occur in one single direction or both directions of a flows.

Note: some use cases may require seeking for users preference or receiving these preferences. Such matters are out of scope.

Signaling Avoidance Leveraging previous experience (), the signaling protocol does not need:

application identity
application cause (or 'reason') to signal metadata
server identity
client-to-server encrypted payload inspection by network elements

Use Cases

Generic Cases

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 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.

Priority Within a Flow (Intra-Flow) Interactive Audio/Video has long been using which runs over UDP. As described in , 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 (, ). 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 -- rather, they originate from a peer (e.g., VoIP, interactive video, peer-to-peer gaming, Remote Desktop). 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. 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.

Detailed Use Cases

Media 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. Examples: Super bowl, On-Demand Streaming Requirement: Signal the flow needs least delay between server and client. Network can provide minimal delay information to the host. Feedback from the network and the client, based on user preference, is required for more efficient streaming. This is required for incorporating special needs based on application/user capabilities and to prioritize traffic during reactive events. Problems:

All packets prioritized the same irrespective of user preferences/needs: a. A client based change in priority of a certain type of data is not possible. For example, a hearing challenged user can choose video over audio while the priority is different for other users. b. 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 time of emergency where video streaming applications share the same priority as SOS signals.
In loss-prone networks or during a reactive policy events, retransmissions cause immense delay. Networks, not able to distinguish between reliable and loss-tolerant data or the critical data within a flow (i-frames, p-frames, and audio packets), can have challenges in efficiently handling/forwarding data.

Solution:

Client to ISP (Host-to-network) signaling can help with conveying user needs. a. The server (content provider) achieves best scalability by sending a single stream with the same per-packet metadata. The client, on the other hand, signaling the ISP to treat certain packets with a different priority over the others, can help solve the issue. For example, for video streaming, if the metadata just said "audio" (0x00), "video i-frame" (0x01) "video p-frame" (0x02), the client could have the signaling protocol tell an upstream router which one was most important. Some users could prioritize video over audio and vice versa. b. Clients occasionally change the importance of receiving certain streams, such as muting video or audio, but still need to receive some frames to populate their playout jitter buffer. In such cases, the client can signal the ISP to (de-)prioritize certain types of traffic during the duration of that event. The per-packet metadata from the server would remain the same while the ISP treats certain per-packet metadata differently. These signals can be propagated to the server (in the form of a network to host signals) for improved efficiency, but this is out of the scope of this document.
Server to ISP (Host-to-network) per packet metadata can help in informing the network about the nature of traffic.

Interactive Media Examples: VoIP (peer-to-peer (P2P), group conferencing), gaming. Requirement: 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. 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 importance can be conveyed in metadata to the network, by signaling from the client to the network element(s). 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. Examples: VoIP, online gaming. Problems:

Peer-to-peer communication often involves direct connection(s) without involvement of an intermediary server (or one of the peers take the role of a server in some gaming cases). The signaling (like DSCP) from these IP addresses are often ignored as these IP addresses are not in the ISPs' list of recognized servers. It is the same fate for servers that are not in the ISPs' list of recognized servers in an online gaming or a conference scenario
Each peer part of the network will have different preferences and it is difficult for the application to modify metadata for each peer based on the preference.

Solutions:

Client-to-network signal indicating ISP to honor the honoring signaling data of a particular flow enables any data, irrespective of whether the sending server is part of the list of IP addresses or not. This enables client(user)-driven processing of metadata and client driven authorization of the IP addresses apart from the ISPs' list of recognized IP addresses.
Client-to-network signaling also helps the ISP treat the same metadata differently for different flows based on the user preference. The per-packet metadata from the server would remain the same, simplifying signaling implementation on the server and making it more scalable.

Examples of Same Type of Metadata with Different 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.

Video in a media session: One user can choose to keep the video and screen-sharing equally distributed on the screen while another user can minimize or reduce the size of the video. Based on the size/preference of the video window, video packets can be prioritized accordingly relative to screen-shared content. This preference can be propagated to the server as network-to-host signaling for more efficient transmission but that is out of the scope of this document.
User Inactivity signal: When the user is inactive during an interactive session such as gaming (activity can be detected automatically or can be a simple user signal of Away-from-Keyboard (AFK)), the client can signal to the ISP to deprioritize the packets to the extent that the client receives some data to populate their playout jitter buffer.

Bulk Data Transfer Examples: backup/restore, software update, RSS feed update, email, printing to a print server, file copy Requirement: Signal the flow as below best-effort. Problem:

Bulk data is generally not interactive and can be forwarded of over paths of greater latency. It is treated as non-time sensitive operation. Although some bulk transfers (like saving a file in the middle of editing) that cannot be minimized, where the user will have to wait till it is completed to further use the device, should be given real-time importance. Bulk data such as printing a file while editing can be parallelized and need not have real-time priority. Similarly, backing up of data can be parallelized while restoring of data cannot be parallelized based on the application.

Solution:

Client-to-network signaling can enhance the user experience by identifying and signaling the flow's priority appropriately for the ISP to handle the packets accordingly.

Mixed Traffic Examples: Desktop Virtualization

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 forwarding mixed traffic for better user interactivity and network performance. ```

Mixed traffic has a large variety of applications with unique cases. For the purpose of use case, Desktop Virtualization is considered below. Problems:

In remote desktop use case, a server can host multiple connections with varying type of traffic to it. These servers are often in a database, 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 ISPs.
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).
With multiple applications running in the same virtualized environment, video streaming having same priority as graphics updates while the user is playing a video in the background while typing a document in the foreground can cause interactivity issues.

Solution:

Client-to-network signal indicating ISP to honor the signaling data of a particular flow enables the servers, that are not even directly visible to the ISPs, to benefit from signaling. This enables client(user)-driven processing of metadata and client driven authorization of the IP addresses apart from the ISPs' list of recognized IP addresses.
Client signaling can reduce/eliminate the resource intensive responsibility of identifying such scenarios and modifying the metadata accordingly. The per-packet metadata from the server would remain the same, simplifying signaling implementation on the server and making it more scalable.
Client signaling based on user activity can improve user experience. Signaling the ISP to treat the same metadata differently based on the user activity can help improve/resolve this, while keeping the per packet metadata the same.

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 (e.g., prefer the use of alternate paths, offload a network).

Operational Considerations

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.

Redundant Functions & 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.

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 ). As such, hints about resource-like metadata is bound by default to the overall network attachment, not specific to a given application or flow.

It is out of the scope of this document to discuss setups (e.g., 3GPP PDU Sessions) where network attachments with GBR (Guaranteed Bit Rate) for specific flows is provided.

Applications 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.

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.

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.

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.

Forwarding Processing: Slow Path vs. Fast Path TBC

Impacts of Nested Congestion Controls TBC

Requirements Summary TODO summary.

The activation of the collaborative signalling MUST NOT lower the perceived service of flows during nominal conditions (i.e., when the network is not in a reactive policy mode).

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

Informative References Content Classification for Traffic Optimization The Internet is for End Users This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users. It also explores how the IETF can more effectively achieve this. Considerations on Application - Network Collaboration Using Path Signals This document discusses principles for designing mechanisms that use or provide path signals and calls for standards action in specific valuable cases. RFC 8558 describes path signals as messages to or from on-path elements and points out that visible information will be used whether or not it is intended as a signal. The principles in this document are intended as guidance for the design of explicit path signals, which are encouraged to be authenticated and include a minimal set of parties to minimize information sharing. These principles can be achieved through mechanisms like encryption of information and establishing trust relationships between entities on a path. Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken) This document is a product of the Path Aware Networking Research Group (PANRG). At the first meeting of the PANRG, the Research Group agreed to catalog and analyze past efforts to develop and deploy Path Aware techniques, most of which were unsuccessful or at most partially successful, in order to extract insights and lessons for Path Aware networking researchers. This document contains that catalog and analysis. RTP: A Transport Protocol for Real-Time Applications This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK] Web Real-Time Communication Use Cases and Requirements This document describes web-based real-time communication use cases. Requirements on the browser functionality are derived from the use cases. This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WG's efforts so far. It is being published to record the early conclusions of the WG. It will not be used as a set of rigid guidelines that specifications and implementations will be held to in the future. An Unreliable Datagram Extension to QUIC This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. Media over QUIC Transport Discord Meta Cisco Google Google This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) Orange Juniper Telefonica Nokia Huawei Technologies This document specifies a YANG service data model for Attachment Circuits (ACs). This model can be used for the provisioning of ACs before or during service provisioning (e.g., Network Slice Service). The document also specifies a service model for managing bearers over which ACs are established. Also, the document specifies a set of reusable groupings. Whether other service models reuse structures defined in the AC models or simply include an AC reference is a design choice of these service models. Utilizing the AC service model to manage ACs over which a service is delivered has the advantage of decoupling service management from upgrading AC components to incorporate recent AC technologies or features.

Acknowledgments Thanks to Hang Shi for the review and comments.