SCONE TCP Option
draft-eddy-tcpm-scone-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Wesley Eddy , Matt Joras | ||
| Last updated | 2025-10-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-eddy-tcpm-scone-00
SCONE W. Eddy
Internet-Draft M. Joras
Intended status: Standards Track Meta
Expires: 23 April 2026 20 October 2025
SCONE TCP Option
draft-eddy-tcpm-scone-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 23 April 2026.
Copyright Notice
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.
Eddy & Joras Expires 23 April 2026 [Page 1]
Internet-Draft SCONE for TCP October 2025
Table of Contents
1. SCONE Background and Introduction . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2
3. TCP Option for SCONE . . . . . . . . . . . . . . . . . . . . 3
3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Use During Handshake . . . . . . . . . . . . . . . . . . 3
3.3. Use Post-Handshake . . . . . . . . . . . . . . . . . . . 4
3.3.1. Endpoint-Included . . . . . . . . . . . . . . . . . . 4
3.3.2. Network-Initiated . . . . . . . . . . . . . . . . . . 4
4. API for TCP Applications . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. SCONE Background and Introduction
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.
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Eddy & Joras Expires 23 April 2026 [Page 2]
Internet-Draft SCONE for TCP October 2025
3. TCP Option for SCONE
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.
3.1. Option Format
1 2 3
0 8 6 4 2
+-----------+------------+-------------------------+
| Kind=TBD | Length=4 | Throughput 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.
3.2. 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.
Eddy & Joras Expires 23 April 2026 [Page 3]
Internet-Draft SCONE for TCP October 2025
3.3. 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 generated by network elements on-demand when
significant conditions change.
3.3.1. Endpoint-Included
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.
3.3.2. Network-Initiated
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.
Eddy & Joras Expires 23 April 2026 [Page 4]
Internet-Draft SCONE for TCP October 2025
4. API for TCP Applications
TODO: describe informationally a possible socket option to request
SCONE use.
TODO: describe informationally a possible socket option to get SCONE
info.
5. 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.
6. IANA Considerations
TODO: TCP option kind value is TBD.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/rfc/rfc9293>.
7.2. Informative References
[I-D.ietf-scone-protocol]
Thomson, M., Huitema, C., Oku, K., Joras, M., and L. M.
Ihlar, "Standard Communication with Network Elements
(SCONE) Protocol", Work in Progress, Internet-Draft,
draft-ietf-scone-protocol-02, 7 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-scone-
protocol-02>.
Eddy & Joras Expires 23 April 2026 [Page 5]
Internet-Draft SCONE for TCP October 2025
[I-D.joras-scone-video-optimization-requirements]
Joras, M., Tomar, A., Tiwari, A., and A. Frindell, "SCONE
Video Optimization Requirements", Work in Progress,
Internet-Draft, draft-joras-scone-video-optimization-
requirements-01, 12 May 2025,
<https://datatracker.ietf.org/doc/html/draft-joras-scone-
video-optimization-requirements-01>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
Acknowledgments
This document represents collaboration and inputs from others,
including:
* Alan Frindell
* Bryan Tan
* Anoop Tomar
Authors' Addresses
Wesley Eddy
Meta
Email: wesleyeddy@meta.com
Matt Joras
Meta
Email: matt.joras@gmail.com
Eddy & Joras Expires 23 April 2026 [Page 6]