| Internet-Draft | SCONE for TCP | October 2025 |
| Eddy & Joras | Expires 23 April 2026 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 April 2026.¶
Copyright (c) 2025 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.¶
Standard Communication with Network Elements (SCONE) [I-D.ietf-scone-protocol] is an extension to QUIC [RFC9000] 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 [I-D.joras-scone-video-optimization-requirements] 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document defines a TCP [RFC9293] 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.¶
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.¶
TODO: Explain the throughput guidance values used, which could be based on the QUIC values.¶
TODO: note assumed interaction with other options, namely TCP-AO.¶
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.¶
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 generated by network elements on-demand when significant conditions change.¶
When endpoints desire to send the SCONE-TCP option, they may either include it within the header of segment carrying data (if there is user data to be sent), or may include SCONE-TCP on any generated non-data-carrying ACK segment, when no gaps exist in the received data.¶
Pure ACKs (without data or SACK information) MUST NOT carry SCONE-TCP when there are gaps in the received data, because the other TCP peer would in-general be challenged to distinguish them from duplicate ACKs that could towards fast retransmission, for instance.¶
Endpoints receiving segments with the SCONE-TCP option MUST NOT treat any pure ACKs that have SCONE-TCP as potential indicators of loss.¶
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.¶
An on-path network element aware of the live TCP flow MAY generate a pure ACK matching the last observed sequence and acknowledgement values sent to the same endpoint, that includes the SCONE-TCP option with new or updated throughput advice, if changed from the last value that it has sent.¶
In general, network devices are highly discouraged from generating TCP segments to the endpoints of connections passing through them. This can be viewed as a type of attack, and could be prevented by use of methods like IPsec, TCP-AO, or by other means between the end hosts. However, in the cases of applications that SCONE serves, these network devices are on-path and may drop, delay, or otherwise manipulate the packet stream.¶
TODO: describe informationally a possible socket option to request SCONE use.¶
TODO: describe informationally a possible socket option to get SCONE info.¶
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.¶
TODO: TCP option kind value is TBD.¶
This document represents collaboration and inputs from others, including:¶