]> Aalyria

wes@aalyria.com

Meta

matt.joras@gmail.com

Web and Internet Transport SCONE SCONE This document describes a TCP option that permits network elements to provide TCP endpoints advice on rate limits within the network. The functionality for TCP is analogous to SCONE packets within the QUIC protocol.

SCONE Background and Introduction Standard Communication with Network Elements (SCONE) is an extension to QUIC that provides the capability for network elements to provide QUIC application endpoints with guidance on potential permitted throughput, e.g. in order to make explicit the presence of traffic limiting mechanisms within the network that can be problematic for video streaming and other applications. In QUIC, SCONE is negotiated between endpoints using a transport parameter, and the QUIC endpoints send SCONE packets periodically. The SCONE packets are visible to network elements that modify the throughput guidance within them.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

TCP Option for SCONE This document defines a TCP option to provide analogous SCONE functionality for TCP. This could be viewed as similar to the way that TCP MSS clamping works traditionally, with the TCP MSS options included by endpoints being inspected and modified en-route by elements on the network path that can provide more pertinent guidance.

Option Format The TCP option kind value (TBD) indicates the SCONE-TCP option. The length value of 4 is always used, along with a two byte throughput guidance. The Throughput Guidance field is 16 bits and takes values based on the QUIC SCONE packet definitions of the "Rate Signal High Bits" (Section on "Rate Signals"). Only the lowest 7 bits of Throughput Guidance are currently used, and the highest 9 bits are zeroed. These may be used in a future extension, and should be ignored by implementations based on this current specification. A rate limit is computed from the value of these 7 bits interpreted as an unsigned integer "n" ranging from 0 to 126, within the formula below.

Use During Handshake Like other TCP options, SCONE-TCP is sent during connection establishment on SYN and SYN-ACK segments, and then only used subsequently if it has been successfully negotiated via use on the handshake. Since it is used on the initial SYN, the SCONE-TCP option can serve as a "client hint" that informs the behavior of traffic limiting mechanisms within the network. Since it is used on the SYN-ACK, the SCONE-TCP option can provide an immediate signal to the endpoint application about the advised bitrate that can help to inform the selection of media content to be requested subsequently within the application.

Use Post-Handshake After TCP connection establishment with successful SCONE-TCP negotiation, the option can be used at any time. It does not need to be sent on every segment, and providing an update may be the sole reason for sending a segment. Since it takes up valuable header space, and will be inspected and operated on by network elements, it is not advisable to set on every segment that is transmitted. Instead, SCONE-TCP options may be included either periodically by an endpoint (e.g. every 10 seconds as a probe before requesting new media chunks) or in response to other events, such as at application request to help determine throughput guidance. When an endpoint TCP desires to send the SCONE-TCP option, it can either include the option within the header of an outgoing segment carrying data (if there is user data to be sent), or may generate a pure ACK segment with the SCONE-TCP option. Endpoints receiving segments with the SCONE-TCP option MUST NOT treat any pure ACKs that have SCONE-TCP as potential indicators of loss (i.e. these are not duplicate acknowledgements caused by gaps in the received data, and should not count towards triggering fast retransmission, for instance).. ACKs that carry SACK information MAY include the SCONE-TCP option. Endpoints receiving these MAY use the SACK information to determine reordering, loss inference, and retransmission behavior.

API for TCP Applications SCONE provides a signal to applications that can be used, for instance, to select proper media from manifests listing different available bitrates (e.g. at different resolutions, etc.) for video data. To that extent, it is important for the SCONE signal information to be made available to TCP applications. Relevant application programming interface (API) details are left to TCP implementations, though this section provides the outline of expected capabilities. Since not all applications would be interested in SCONE throughput advice, the option might only be enabled for negotiation by specific application request. In that case, a TCP implementation supporting the typical "socket" API might define arguments for the "setsockopt" call to request SCONE use. Similarly, the "getsockopt" call might be used in order to supply any received SCONE thoughput guidance back to the application. In some use cases, this may only need to happen once, early in the connection (e.g. after receiving a video manifest), while in other cases, an application may need to periodically poll the advice using getsockopt calls to sense if the advice may have changed over time.

Security Considerations The security considerations for SCONE-TCP are similar to those for SCONE as present in QUIC, however, some differences arise because TCP security lacks the same cryptographic methods that are present in QUIC. Middleboxes making changes to TCP headers (and options such as SCONE-TCP) might be considered as an attack, or used as part of an attack, although in general this is already common due to NAT, MSS clamping, and other network features. TCP headers can be protected by TCP-MD5 , which is a legacy obsolete option, that does not cover the TCP options, so is compatible with the use of SCONE-TCP and the modification of SCONE-TCP options by middleboxes. TCP-AO replaces TCP-MD5 and can be configured to protect TCP options, or to leave TCP options uncovered by its MAC. If TCP-AO is used and configured to protect TCP options, then SCONE-TCP SHOULD NOT be used, as any modifications of it would cause segments to be rejected.

IANA Considerations If this document is approved for Standards Track, a TCP option kind value should be allocated. In early use, a TCP experimental option kind value can be used, with the ExID value 0x6f7d that has been registered with IANA. This matches 15 bits of both of the QUIC version numbers used for SCONE.

References Normative References 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. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo describes a TCP extension to enhance security for BGP. [STANDARDS-TRACK] This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [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. Meta Platforms, Inc. Meta Platforms, Inc. Meta Platforms, Inc. Meta Platforms, Inc. These are the requirements for the "Video Optimization" use-case for the SCONE topic, which broadly speaking seeks to optimize video playback experience in mobile networks by cooperative communication between video content providers and the providers of network services to end users. Mozilla Private Octopus Inc. Fastly Meta Ericsson This document describes a protocol where on-path network elements can communicate their perspective on the maximum sustainable throughput for QUIC flows to endpoints. This throughput advice suggests an upper bound on long-term average throughput, independent of and complementary to real-time congestion control signals.

Acknowledgments This document represents collaboration and inputs from others, including:

• Alan Frindell
• Bryan Tan
• Anoop Tomar

Wesley Eddy's original work on this was supported while a contractor of Meta.