]> Futurewei

john.kaippallimalil@futurewei.com

Cloud Software Group Holdings, Inc.

danwing@gmail.com

Cisco

sgundave@cisco.com

Cloud Software Group Holdings, Inc.

Sridharan.girish@gmail.com

Tencent America LLC

spencerdawkins.ietf@gmail.com

Orange

Rennes 35000 France mohamed.boucadair@orange.com

Transport Transport and Services Working Group Media Low Latency Wireless Links Bandwidth constraints Policy Operational Considerations Collaborative signaling from host-to-network (i.e., client-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 signaling may be enabled so that clients and servers are aware of the network's treatment of incoming packets. Also, client-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/client and the network. This document lists some use cases that illustrate the need for a mechanism to share metadata and outlines host-to-network requirements. The document focuses on signaling information about a UDP transport flow (UDP 4-tuple). About This Document Status information for this document may be found at . Discussion of this document takes place on the TSVWG Working Group mailing list (), which is archived at . Subscribe at .

Introduction Wireless networks, including 5G and WLAN, inherently experience large variations in link quality over sub-RTT (round-trip time) intervals and on the other hand, applications such as interactive media demand both low latency and high bandwidth. Superior service during adverse network events can be achieved by the sender conveying packet behavior preferences to the network for packets within a single UDP 4-tuple flow. During adverse network events this allows the network to be informed about the least-impactful packets to drop (or delay) in the same UDP 4-tuple flow. Without such signaling, the network can only indiscriminately drop (or delay) packets. With such capability, loss-tolerant and delay-tolerant transport protocols such as RTP , QUIC , and Unreliable QUIC can inform the network and provide a superior end user experience. Some of the complications that are induced by adverse network events 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. This document focuses on host-to-network collaboration, which covers both client-to-network (C2N) and server-to-network (S2N) directions. discusses the rationale for per-packet metadata. outlines use cases to illustrate the issues and the need for additional information per flow to allow the network to optimize its handling. describes the requirements for on-path media collaboration signals. provides operational constraints in the network.

Definitions The document makes use of the following terms:

Host:

Refers to an endpoint that is connected to a network (called, client) or a server that delivers a service to a client.

Per-Flow Metadata:

Refers to metadata that doesn't change often during the lifetime of a connection and thus can be exchanged once or as needed. This is communicated per flow (i.e., UDP 4-tuple) between client and network.

Examples of such metadata are client request to honor per-packet metadata and preferences.

Per-Packet Metadata:

Refers to metadata that varies packet to packet within the same flow, often capturing the nature and characteristics of the traffic each packet carries. This needs to be communicated on a per packet basis.

Examples of such metadata are Packet Priority and tolerance to delay

Reactive Management:

Network management actions that are undertaken as a reaction to unplanned overload events. Concretely, this includes policies which react to congestion events with very short to very long durations (e.g., varying wireless and mobile air interface conditions) or protection policies to soften the impact of ongoing attacks.

Rationale for Per-packet Metadata Maximizing network utilization and enhancing user experience under adverse conditions are challenging. Wireless networks face issues like channel condition changes, cell interference, and user mobility. These variations can occur in milliseconds , while congestion control takes tens of milliseconds (more than one RTT) to estimate data rate. Application servers encoding live or interactive content also take time to adjust to network rates. End-to-end congestion control algorithms (CCAs) are suboptimal when link quality varies in sub-RTT timeframes and applications need low latency and high bandwidth (e.g., ). Applications settle for lower throughput when prioritizing latency or higher throughput with higher delays. Feedback-based rate control for a flow (UDP 4-tuple) cannot adapt to sub-RTT wireless channel changes. Application servers can provide per-packet information for network shapers to allocate resources effectively. Heuristics can build an “implicit signal” from unencrypted packets to prioritize flows, but this leads to protocol ossification . Encrypted packets make implicit signals unviable. Bandwidth constraints are most prominent in access networks (e.g., radio access networks). Users, serviced via these networks, use clients with varying connectivity needs for optimal experiences, which change over time based on application usage. Explicit signals to clients can help manage bandwidth better. Interactive media applications and likewise demand high throughput and low latency, sometimes carrying different streams (e.g., audio and video) in a single connection (e.g., WebRTC ). With RTP , media type could be used as an implicit signal for determining relative priority. However, encrypts RTP header extensions and Contributing sources (CSRCs). Fully encrypted transport (e.g., QUIC ) does not expose media header information for network decisions.

E2E Media Transport Overview

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

Metadata and Network Shaping | +--------+ | | | | | | | Network| | downstream packet | | | |<=============+=+ Shaper +<+=========================+ | | | | +--------+ | (B) on-path S2N metadata| | +------+ +------------+ +------+ Client Router Server ]]>

shows a bottleneck (access) router on the Server to Client path. A network shaper in the router manages QoS of multiple users’ flows and can buffer, discard, or apply other flow control rules. Application layer signaling and feedback between Client and Server (A - in the figure) adjust transmission rate over several RTTs using feedback and CCAs, settling to a steady rate to avoid excessive packet loss. In networks where link conditions (between Client and Router) vary significantly at sub-RTT timescales, this results in unused bandwidth at short timescales. Research (e.g., ) indicates that media applications can achieve better QoE when sending at a higher rate (less conservative than current CCA) and tolerating some packet loss or delay of low priority packets. Packet priority and tolerance to delay in such cases would be provided on-path in a side channel associated with the downstream packet (B). The requirements for this server-to-network (S2N) metadata are described in . The client may provide information to an (access) router to drop 'lower priority'-marked packets of a flow (UDP 4-tuple) temporarily which can in turn allocate available bandwidth to other flows of that network attachment, especially during a reactive management event. Network shapers observe flows and apply policies to maximize performancebut are unaware underlying flows belinging to the same user and network attachment (e.g., a subscriber connection, a 3GPP PDU Session). Clients may provide information to an (access) router to drop 'lower priority'-marked packets of a flow (UDP 4-tuple) temporarily during congestion, allowing bandwidth allocation to other flows of the same network attachment. 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.

Requirements Definition

Server-to-Network (S2N)

REQ-PACKET-PRIORITY:

Server indicates the importance of a packet within a flow. This allows the network to prioritize based on requirement and during a Reactive Management event. This priority value may also be used to indicate loss tolerance and the network elements may drop loss tolerant packets during Reactive Management events.

This is a per-packet metadata requirement.

REQ-PACKET-DELAY:

Metadata to indicate whether the packet can tolerate delay.

This is a per-packet metadata requirement.

Client-to-Network (C2N)

REQ-CLIENT-DECIDES:

User/Client indicating to the network to honor the application's metadata signaling.

This is a per-flow metadata requirement.

REQ-PAYLOAD-CLIENT-DECIDES:

The ability of the receiver to change the priority by communicating to the network to prioritize one payload(metadata) over another within the flow -- without cooperation of the sender. Gives the sender the ability to have same metadata for all the connections without having to change based on the user preference, aids in scalability.

This is a per-flow metadata requirement.

API

REQ-API-FRAMEWORK:

API framework to facilitate signaling for applications.

Signaling from client to network () and server to network ()) is best facilitated by Application Programming Interfaces (APIs). Signaling and retrieval of the signals may not be performed at a single layer (although not encouraged). Hence, for server to network signaling, a framework is required to abstract the underlying per-packet metadata protocol(s) and allow the application(s) to retrieve/send signals using a single or a set of APIs 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 on a client can consume the signals.

The API framework uses the medium negotiated under to send/receive the signals.

System Considerations

REQ-PRIVACY-ADDITIONAL:

An on-path observer obtains (or gleans) no additional information about the IP packet.

REQ-SIGNALING-AVOIDANCE:

Leveraging previous experience , the following is not required to make use of the collaborative signaling:

• Reveal the application identity.
• Expose the application cause (or 'reason') to signal metadata.
• Reveal the server identity.
• Inspect client-to-server encrypted payload by network elements.

Use Cases

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. Examples: live broadcast, on-demand video streaming. Use cases:

1. The majority of streaming traffic is Audio and Video traffic. Audio traffic is more critical than video for many applications and vice-versa for some. This differences in priority needs to be indicated to the network to ensure network (de)prioritizes (or even drop if deemed necessary) traffic appropriately. Requirement: REQ-PACKET-PRIORITY. Impact: With the above requirement met, better quality of service could be maintained in resource-constrained networks and during Reactive Management events ensuring better user experience.
2. The server (or relay) sends the same stream to many receivers, including the same metadata (especially with media over QUIC). Different clients have different priorities for different types of traffic. This would result in change in priorities for the same type of traffic that a single server sends, based on the user/client. Requirement: REQ-PAYLOAD-CLIENT-DECIDES. Impact: With the above requirement met, each client/user preferences are prioritized accordingly while maintaining scalability on the server, since the metadata that the server sends still remains the same for all the connections.
3. In loss-prone networks or during Reactive Management events, if all packets of an application flow (UDP 4-tuple) such as live broadcast or on-demand video streaming are treated the same, it limits the ability to maximize network utilization and use the transiently available bandwidth. Dropping or delaying of (media) packets randomly is likely to lower network utilization and application performance. Requirement: REQ-PACKET-PRIORITY, REQ-PACKET-DELAY. Impact: By identifying packets that tolerate being dropped, congestion can be reduced leading to improved performance/quality of service.

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. This can also include mixed traffic based on the user activity and interaction. Examples: VoIP (Peer-to-Peer (P2P), group conferencing), gaming, Remote Desktop Virtualization, eXtended Reality (XR). Use cases:

1. A mobile/roaming user prioritizes audio over video during a VoIP call to have a seamless meeting experience. Requirement: REQ-PAYLOAD-CLIENT-DECIDES. Impact: With the above requirement met, each client/user preferences are prioritized accordingly while maintaining scalability on the server.
2. A remote desktop user prioritizes graphics updates over an on-going file copy operation. A user types in/interacts with a document/file after triggering a save file operation, while save operation is on-going. Requirement: REQ-PACKET-PRIORITY, REQ-PACKET-DELAY. Impact: By prioritizing graphic updates/interactive traffic, user interactivity is improved with lesser jitter.
3. A game or VoIP application may want to signal different metadata for the same type of packet in each direction. One user, in a VoIP conference call, wants to prioritize the slide deck being shared while the other wants to prioritize audio and other wants to prioritize video of the speaker. Each user's varied preferences can be catered with same type of metadata originating from the server. Requirement: REQ-PACKET-PRIORITY, REQ-PAYLOAD-CLIENT-DECIDES. Impact: With the above requirement met, each client/user preferences are prioritized accordingly while maintaining scalability on the server.
4. A network glitch while user is in an eXtended Reality application. The traffic comprises of haptic, video, audio, graphics update and keystrokes. During such a Reactive Management event, some packets need to be deprioritized/dropped to maintain interactivity. Requirement: REQ-PACKET-PRIORITY, REQ-PACKET-DELAY. Impact: By prioritizing high priority traffic, user's interactive experience is improved with lesser jitter.

Metadata Negotiation Support Currently, some flows are granted higher priority over other flows because of a contractual agreement between the ISP and the content provider. These contracts could be extended to also allow per-packet metadata within a single UDP 4-tuple, as desired by this document (). However, these sorts of agreements favor large content providers and major ISPs, disfavoring smaller providers and smaller ISPs while also preventing other network topologies such as peer-to-peer networking (e.g., VoIP) as that traffic does not originate from a contracted content provider. For all applications to benefit from per-packet prioritization within a single UDP 4-tuple, the client needs to communicate with the ISP to determine which per-packet markings are supported by the ISP's network (e.g., encoded into IPv6 Flow Label, UDP Option, or DSCP). Then it can indicate to the ISP's network that a certain UDP 4-tuple will have those markings and instruct the server to generate those per-packet metadata markings. There might be many channels to signal the Server-to-Network per-packet metadata such as (non-exhaustive list):

• TCP options
• UDP Options
• IPv6 Hop-by-Hop Options ()
• QUIC CID mapping
• ICMP messages

Requirements: REQ-API-FRAMEWORK and REQ-CLIENT-DECIDES. Impact: By signaling ISPs to honor the metadata for a particular flow, the client facilitates identifying important packets to the ISP enhancing packet delay or drop decisions during Reactive Management events.

API Framework: Client learns ISP capabilities and signals how incoming IP packets will signal network collaboration | | Network Collaboration Capabilities? | | | |<--------------------------------------------------| | my Network Collaboration capabilities | | | |-------------------------------------------------->| | Server will mark packets using "method #4" | | | |<--------------------------------------------------| | ok | ]]>

On-path Metadata Requirements There are various approaches for collaborative signaling between the server/client 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 and . Leveraging previous experience (), the metadata signals do not need application identity, application cause (or 'reason'), server identity or the inspection of client-to-server encrypted payload. The metadata connections may be between server and network (in either direction) or between client and network (in either direction). Some use cases benefit from server-network metadata exchanges () after first performing a client-network metadata exchange (). 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.

Client-Network Metadata Client-to-network metadata is critical in both identifying the flow that contains metadata as well as negotiate the medium of signaling of metadata.

Client-Network Flow Authorization and Negotiation By signaling the ISP, a client can authorize the ISP to honor incoming per-packet metadata for a certain flow (UDP 4-tuple). This same signal also allows negotiating capabilities discussed in ) and sharing the keys necessary for encrypting or obfuscating server-to-network per- packet metadata recommended in . REQ-CLIENT-DECIDES is satisfied by signaling Client Flow Authorization as part of client-to-network signal.

Server-Network Metadata Application flows (UDP 4-tuple) for live media, eXtended Reality (XR), and gaming require high bandwidth and low latency. In wireless networks, some bandwidth cannot be scheduled using feedback-based rate control due to significant link variations at sub-RTT timescales. Congestion control algorithms settle to a steady rate to avoid excessive packet loss. Feedback via ECN/L4S provides an accurate signal but lacks finer resolution information of instantaneous bandwidth available. If application packets can tolerate delay or some loss of lower priority packets, the network traffic shaper and scheduler can use this information to provide higher application quality of service . The metadata in should satisfy constraints identified in . Privacy requires that metadata should not provide additional information to identify the application or user. The application server can decide on metadata values that provide the best handling for packets and may not reflect exact priority values. This metadata is advisory, and network traffic policy that restricts its use would not result in additional issues. Other constraints include scale () and continuity (). Realizing the additional bandwidth potential with these metadata may require a higher sending rate for the transport flow, which is not specified in this document. Network shapers and schedulers can use the metadata in , but further details are out of scope. Previous work in has identified the general problem, but the solution in is specific to a 5G network. The metadata sent from a dedicated 5G application server identifies PDU set information and end-of-burst signals, which are not understood by non-3GPP systems such as Wi-Fi or DOCSIS. Further, 3GPP functions and policy configurations are required since this is a 5G specific solution. The metadata disclosed in the 5G solution also identifies frame boundaries and does not fully conform to the constraints for privacy or minimality of data identified in .

Packet Priority Per-packet priority information provides the priority level of one packet relative to other packets within a transport flow (UDP 4-tuple). When a packet is marked with high priority, the expectation is that during a Reactive Management event, the network will give high importance to forwarding the packet compared to a packet marked with low priority. The application server can decide on the priority or importance values that provide the best handling for the packets of the transport flow. When more than one application stream (e.g., video, audio) is sent on the same transport flow, the application server decides the best allocation of priority values across the different streams of the flow. Per-packet priority or importance determines the drop priority of a packet. REQ-PACKET-PRIORITY is satisfied by signaling Packet Priority as part of server-to-network metadata.

Tolerance to Delay Some packets of a media flow (UDP 4-tuple) can tolerate more delay over the wire than others (e.g., packets carrying live media frames require very low latency while packets carrying a background image for augmented reality can tolerate more delay). The objective of this metadata is to indicate that these packets can tolerate a limited amount of delay when there is severe congestion or limited bandwidth. Similar to the LE PHB for flows, the expectation is that in this case, each packet marked with this metadata is dropped during a Reactive Management event. As with per-packet priority in , the application server can decide on the metadata values that provide the best handling for the packets of the transport flow. REQ-PACKET-DELAY is satisfied by signaling Tolerance to Delay as part of server-to-network metadata.

System Considerations Traffic policing and shaping are enforced in ingress/egress network points for various reasons (protect the network against attacks, ensure conformance with a traffic profile, etc.). Out-of-profile traffic may be discarded or assigned another class (e.g., using Lower Effort Per-Domain Behavior (LE PDB) ) 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 client-network modes of sending metadata.

Privacy Considerations Media flows are vulnerable to traffic analysis even without per-packet metadata (see, e.g., ). The security aspects of the media payload / transport are not in the scope of this document; these are mentioned here only to provide context for metadata privacy. Protocols such as TLS, SRTP, and QUIC offer some mitigations (like padding) but are vulnerable to traffic analysis (). Per-packet metadata can aid in traffic analysis. Hence, it is recommended to encrypt or obfuscate the metadata information so it is only available to the server, client, and authorized network elements. However, encryption/obfuscation of per-packet metadata is ineffective if the threat resides in the same network entity with keys to decrypt the metadata. The method of encryption or obfuscation is out of scope. To best preserve privacy, implementations might also consider less granular per-packet marking, for example marking all audio and video packets the same and only marking a background data transfer with different metadata. Analysis to ensure that metadata exposure does not compromise user privacy or allow unauthorized entities to infer sensitive information, while maintaining minimal resource consumption is crucial. There is a tension between resource consumption of such encryption and the user's privacy (). REQ-PRIVACY-ADDITIONAL and REQ-SIGNALING-AVOIDANCE are satisfied by not revealing any information that could identify the application's identity, reason to signal, server identity, and securing the metadata.

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.

IANA Considerations None.

Security Considerations Security aspects for the metadata are discussed in . The principles outlined in , , and contain security considerations and are referenced in . Per-packet metadata can be vulnerable to modification in transit by on-path attackers, who can corrupt checksums, drop packets, or modify metadata. Such changes can be detected by the receiver. Since the document focuses only on priorities within a flow (not specifying inter-flow priority), the document does not induce concerns related to a specific user or client declaring all flows or a subset of them as being more important. Such abuse concerns are thus not applicable. Privacy-related considerations are discussed in .

Informative References 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] This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet-scale solutions can be confidently engineered and deployed. This document is not an Internet Standards Track specification; it is published for informational purposes. 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. This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web". It intends to serve as a starting and coordination point to make sure that (1) all the parts that are needed to achieve this goal are findable and (2) the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an applicability statement -- it does not itself specify any protocol, but it specifies which other specifications implementations are supposed to follow to be compliant with Web Real-Time Communication (WebRTC). While the Secure Real-time Transport Protocol (SRTP) provides confidentiality for the contents of a media packet, a significant amount of metadata is left unprotected, including RTP header extensions and contributing sources (CSRCs). However, this data can be moderately sensitive in many applications. While there have been previous attempts to protect this data, they have had limited deployment, due to complexity as well as technical limitations. This document updates RFC 3711, the SRTP specification, and defines Cryptex as a new mechanism that completely encrypts header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of facilitating deployment. 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. This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. Independent Consultant Unaffiliated Transport protocols are extended through the use of transport header options. This document updates RFC 768 (UDP) by indicating the location, syntax, and semantics for UDP transport layer options within the surplus area after the end of the UDP user data but before the end of the IP length. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used. This specification defines the protocol to be used for a new network service called Low Latency, Low Loss, and Scalable throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer that is similar to the original (or 'Classic') ECN approach, except as specified within. L4S uses 'Scalable' congestion control, which induces much more frequent control signals from the network, and it responds to them with much more fine-grained adjustments so that very low (typically sub-millisecond on average) and consistently low queuing delay becomes possible for L4S traffic without compromising link utilization. Thus, even capacity-seeking (TCP-like) traffic can have high bandwidth and very low delay at the same time, even during periods of high traffic load. The L4S identifier defined in this document distinguishes L4S from 'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network bottlenecks can be incrementally modified to distinguish and isolate existing traffic that still follows the Classic behaviour, to prevent it from degrading the low queuing delay and low loss of L4S traffic. This Experimental specification defines the rules that L4S transports and network elements need to follow, with the intention that L4S flows neither harm each other's performance nor that of Classic traffic. It also suggests open questions to be investigated during experimentation. Examples of new Active Queue Management (AQM) marking algorithms and new transports (whether TCP-like or real time) are specified separately. This document specifies properties and characteristics of a Lower- Effort Per-Hop Behavior (LE PHB). The primary objective of this LE PHB is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, BE traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LE PHB. This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification. This document proposes a differentiated services per-domain behavior (PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best-effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. Cloud Software Group Holdings, Inc. Cloud Software Group Holdings, Inc. Orange Nokia 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. Futurewei Cisco Tencent America LLC Wireless networks like 5G cellular or Wi-Fi experience significant variations in link capacity over short intervals due to wireless channel conditions, interference, or the end-user's movement. These variations in capacity take place in the order of hundreds of milliseconds and is much too fast for end-to-end congestion signaling by itself to convey the changes for an application to adapt. Media applications on the other hand demand both high throughput and low latency, and may adjust the size and quality of a stream to network bandwidth available or dynamic change in content coded. However, catering to such media flows over a radio link with rapid changes in capacity requires the buffers and congestion to be managed carefully. Wireless networks need additional information to manage radio resources optimally to maximize network utilization and application performance. This draft provides requirements on metadata about the media transported, its scalability, privacy, and other related considerations. Note: The solution in this draft will be revised to address requirements defined in [draft-kwbdgrr-tsvwg-net-collab-rqmts].

Extended Requirements Definition

REQ-MEDIA-AV-SEPARATE:

Audio can be prioritized differently than video.

This requirement may be generalized to non-media packet types.

This is an enhanced requirement that requires e2e application layer signaling (out of scope here) to identify of frame boundaries and may not be suitable in cases which are sensitive to traffic analysis (see REQ-SIGNALING-AVOIDANCE and ). If the application provides frame boundaries, the client signals the enhanced application priority values in REQ-PAYLOAD-CLIENT-DECIDES.

This is a per-flow metadata requirement.

REQ-MEDIA-KEYFRAME:

Video contains prediction frames and full frames, which need to be distinguished so that full frames can be indicated to the network.

This is an enhanced requirement that requires e2e application layer signaling (out of scope here) to identify of frame boundaries and may not be suitable in cases which are sensitive to traffic analysis (see REQ-SIGNALING-AVOIDANCE and ). If the application provides frame boundaries, the client signals the enhanced application priority values in REQ-PAYLOAD-CLIENT-DECIDES.

This is a per-packet metadata requirement.

REQ-CONTINUITY:

Handover from one radio or router to another should continue to provide same service level.

REQ-MULTIPLE-BOTTLENECKS:

Signaling should support Multiple bottlenecks.

The network must identify multiple bottlenecks, including those within the ISP and subscriber networks, ensuring all bottlenecks benefit from network/client collaboration to enhance overall performance.

REQ-SINGLE-CHANNEL:

The network should use a single channel for sharing metadata to simplify the process and avoid the need for redundant functions.

REQ-ISP-SCALE:

The metadata and other state information that a router has to maintain for each additional flow it handles should be kept to a minimum or eliminated altogether.

Extended Use-Cases

Media Streaming Extended 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. Examples:

1. Audio is more critical than video for many applications and should be prioritized differently than video. Requirement: REQ-MEDIA-AV-SEPARATE.
2. Video contains prediction frames and full frames, which need to be distinguished so that full frames can be indicated to the network. Requirement: REQ-MEDIA-KEYFRAME.

Extended System Considerations

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.

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

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/client collaboration. Requirement: REQ-MULTIPLE-BOTTLENECKS.

Scalability There may be a large number of 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. Requirement: REQ-ISP-SCALE.

Acknowledgments This document is a merge of and . T. Reddy contributed text and ideas to this document.

Acknowledgments from :

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 client/server 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 client-to-network signaling. Thanks to Luis Miguel Contreras, Colin Kahn, Marcus Ilhar and Tianji Jiang for their review and comments.