TCP Packet Trimming Extension
draft-mazilu-tcpm-packet-trimming-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 | Flavius-Romeo Mazilu , Valentin Ionut Bobaru , Costin Raiciu | ||
| Last updated | 2026-07-06 | ||
| 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-mazilu-tcpm-packet-trimming-00
Network Working Group F. Mazilu
Internet-Draft V. Bobaru
Intended status: Standards Track POLITEHNICA Bucharest
Expires: 7 January 2027 C. Raiciu
POLITEHNICA Bucharest / Broadcom Inc.
6 July 2026
TCP Packet Trimming Extension
draft-mazilu-tcpm-packet-trimming-00
Abstract
This document specifies a TCP extension that enables TCP endpoints in
data center networks or similarly controlled administrative domains
to use packet trimming information when it is available. When switch
buffers exceed a threshold, rather than silently dropping a packet,
the switch trims the payload and forwards the header. This allows
the destination to issue a deterministic Negative Acknowledgment
(NACK), enabling faster, more deterministic loss recovery.
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 7 January 2027.
Copyright Notice
Copyright (c) 2026 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
Mazilu, et al. Expires 7 January 2027 [Page 1]
Internet-Draft TCP Trimming July 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. TCP Extensions for Packet Trimming . . . . . . . . . . . . . 4
3.1. Capability Negotiation (Trimming Permitted) . . . . . . . 4
3.2. Trimming NACK Option . . . . . . . . . . . . . . . . . . 4
3.3. Basic Trimming Packet Flow . . . . . . . . . . . . . . . 5
3.4. Effects of Trimming on TCP Checksum and Payload . . . . . 6
4. Data Receiver Behavior upon Receiving a Trimmed Packet . . . 6
4.1. Bypassing TCP Checksum Validation . . . . . . . . . . . . 6
4.2. Ignoring Remaining Payload . . . . . . . . . . . . . . . 6
4.3. Generating the NACK Packet . . . . . . . . . . . . . . . 6
5. Data Sender Behavior upon Receiving a NACK . . . . . . . . . 7
5.1. Identifying and Retransmitting the Lost Segment . . . . . 7
5.2. Entering Fast Recovery . . . . . . . . . . . . . . . . . 7
6. DSCP Marking Strategy . . . . . . . . . . . . . . . . . . . . 7
7. Interaction with Existing Loss Detection Mechanisms . . . . . 8
7.1. Interaction with RACK-TLP . . . . . . . . . . . . . . . . 9
8. Congestion Control Considerations . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9.1. TCP Options . . . . . . . . . . . . . . . . . . . . . . . 11
9.2. Differentiated Services Codepoints . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10.1. Forged NACK Injection . . . . . . . . . . . . . . . . . 12
10.2. Risks of Bypassing the TCP Checksum . . . . . . . . . . 13
10.3. DSCP Remarking and Priority Abuse . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
TCP's congestion control relies primarily on packet loss as a signal
of congestion, or Explicit Congestion Notification (ECN) [RFC3168] as
a proactive measure. The accuracy and speed of these signals are
vital for a mechanism to adapt quickly and utilize available
bandwidth efficiently.
Mazilu, et al. Expires 7 January 2027 [Page 2]
Internet-Draft TCP Trimming July 2026
It is widely recognized that falling back to a Retransmission Timeout
(RTO) [RFC6298] is undesirable. RTOs are overly conservative,
drastically reduce the congestion window to one segment, and impose a
high latency penalty (traditionally bounded to a 1-second minimum,
though modern implementations often use around 300 ms).
For these reasons, fast retransmit [RFC5681] is always preferred, as
it recovers from loss much faster. The duplicate acknowledgment
(DupAck) heuristic was the first method introduced to achieve this,
but it suffers in environments with high packet reordering, short
flows, or when packets at the end of a flight are lost (tail loss).
RACK-TLP [RFC8985] represents a more modern approach, utilizing a
Tail Loss Probe (TLP) for tail losses and replacing sequence-based
DupAck counting with time-based inferences derived from per-segment
transmit timestamps.
However, because these approaches are fundamentally heuristics, they
can fail to detect lost packets in time (forcing an RTO) or trigger
false retransmissions, particularly in networks with significant
packet reordering.
Packet Trimming offers a deterministic alternative. Originally
introduced in the Ultra Ethernet Consortium's specifications
[UEC-SPEC], this approach is gaining support in modern network switch
hardware. When switch buffers get full or exceed a certain threshold
(as in Active Queue Management), rather than silently dropping the
packet, the switch trims the payload. It retains only the bytes up
to the transport header and forwards this "trimmed" packet to the
destination.
By using Differentiated Services Code Point (DSCP) markings
[RFC2474], the network can inform the destination of the trimming
event. The destination then issues a Negative Acknowledgment (NACK)
carrying the specific sequence number of the affected packet,
eliminating the need for the data sender to rely on heuristics to
determine what to retransmit.
This document defines the TCP signaling and endpoint behavior needed
to use this information in data center networks or similarly
controlled administrative domains. It does not specify how a network
is configured for packet trimming, which packets a switch chooses to
trim, or how DSCP values are provisioned inside such a domain. That
network-side configuration is outside the scope of this document;
deployments can refer to the Ultra Ethernet Consortium specifications
[UEC-SPEC].
Mazilu, et al. Expires 7 January 2027 [Page 3]
Internet-Draft TCP Trimming July 2026
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD 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.
3. TCP Extensions for Packet Trimming
All additional state and signaling required between the two
communicating hosts are carried as TCP options.
3.1. Capability Negotiation (Trimming Permitted)
If both endpoints support packet trimming, they SHOULD set the
DSCP_TRIMMABLE codepoint on all data packets. However, to prevent a
scenario where a sender marks packets as trimmable but the receiver
does not understand how to process trimmed packets or issue NACKs,
capability negotiation is required.
A new TCP option, Trimming Permitted, MUST be exchanged during the
three-way handshake. Only if both the SYN and SYN+ACK packets carry
this option will the subsequent data packets be considered trimmable.
This option MUST NOT be set on non-SYN packets. It is similar in
this regard to the SACK Permitted option [RFC2018].
TCP Trimming Permitted Option Format:
+----------+----------+
| Kind=TBD | Length=2 |
+----------+----------+
Figure 1
3.2. Trimming NACK Option
When congestion occurs at a network switch along the path, the switch
trims the payload of trimmable packets, updates the IP header to
DSCP_TRIMMED, and forwards the header to the data receiver.
Upon receiving a packet, the data receiver inspects the DSCP field.
If the packet is marked as DSCP_TRIMMED, the receiver MUST
immediately issue a new TCP packet with no data payload, carrying the
Trimming NACK option. This option contains the sequence number of
the trimmed packet. The receiver MAY include other options in this
packet (e.g., SACK blocks [RFC2018]); there is not any requirement
for NACK to be the only option set.
Mazilu, et al. Expires 7 January 2027 [Page 4]
Internet-Draft TCP Trimming July 2026
Trimming NACK Option Format:
Kind: TBD
Length: 6 bytes
Payload: 4 bytes (NACK sequence number)
+-----------+---------+------------+
| Kind= TBD | Length=6| Payload 4B |
+-----------+---------+------------+
Figure 2
3.3. Basic Trimming Packet Flow
The following diagram illustrates the flow of packets when congestion
occurs and a packet is trimmed:
Event TCP DATA SENDER TCP DATA RECEIVER
_____ ____________________________________________________________
1. [Sends Full Packet] --> [Receives Header Only]
Format: IP|TCP|Payload Format: IP|TCP
DSCP: DSCP_TRIMMABLE DSCP: DSCP_TRIMMED
SEQ: X SEQ: X
(Receiver detects Payload
removal via DSCP change)
<-- [Sends NACK Signal]
Format: IP|TCP
Options: NACK X
2. Receive NACK X
(Triggers instant recovery
of original payload)
Retransmit segment X --> [Receives Full Packet]
Format: IP|TCP|Payload Format: IP|TCP|Payload
DSCP: DSCP_TRIMMABLE DSCP: DSCP_TRIMMABLE
SEQ: X SEQ: X
Figure 3
Mazilu, et al. Expires 7 January 2027 [Page 5]
Internet-Draft TCP Trimming July 2026
3.4. Effects of Trimming on TCP Checksum and Payload
When a switch trims a packet, it updates the relevant IP header
fields, including Total Length, Time to Live, Differentiated Services
Code Point (DSCP), and IP Checksum. However, to avoid the high
computational cost of parsing transport-layer headers, the switch
does not update the TCP header [RFC9293]. Consequently, the TCP
checksum remains calculated against the original, full payload,
rendering it invalid for the trimmed packet.
Switches may not trim the payload precisely at the TCP header
boundary, as doing so requires parsing variable-length TCP headers to
locate the data offset. Therefore, a trimmed packet may still
contain a partial payload fragment. Since the TCP checksum is
invalid, the integrity of this data cannot be verified.
4. Data Receiver Behavior upon Receiving a Trimmed Packet
4.1. Bypassing TCP Checksum Validation
When a TCP data receiver identifies a trimmed packet by observing the
DSCP_TRIMMED codepoint in the IP header, it MUST skip the standard
TCP checksum verification for that packet, because trimming removes
payload bytes that were covered by the original checksum. The
receiver MUST process the packet only according to the trimmed-packet
rules in this section; it MUST NOT treat the packet as ordinary TCP
data.
The checksum effects of trimming are described in Section 3.4.
Security considerations for bypassing checksum validation are
discussed in Section 10.2.
4.2. Ignoring Remaining Payload
A trimmed packet may still contain payload bytes after the TCP
header. The data receiver MUST NOT process, acknowledge, or deliver
any payload data remaining in the trimmed packet.
4.3. Generating the NACK Packet
Upon processing a valid trimmed packet, the data receiver SHOULD
immediately generate and transmit a new TCP packet to the data
sender. This packet MUST NOT contain any payload data. It MUST
include the NACK TCP option.
The NACK option payload is 4 bytes in length and MUST contain the
sequence number extracted from the received trimmed packet.
Mazilu, et al. Expires 7 January 2027 [Page 6]
Internet-Draft TCP Trimming July 2026
5. Data Sender Behavior upon Receiving a NACK
5.1. Identifying and Retransmitting the Lost Segment
Upon receiving a TCP packet containing a NACK option, the data sender
should extract the sequence number from the NACK option payload and
locate the corresponding unacknowledged data segment in its
retransmission queue.
Due to mechanisms such as TCP Segmentation Offload (TSO) or middlebox
fragmentation, the sequence number reported in the NACK might not
match the exact starting sequence number of a segment in the data
sender's queue. The data sender should identify the segment where
the sequence space covers the NACKed sequence number (i.e.,
Segment.SEQ <= NACK.SEQ < Segment.SEQ + Segment.LEN).
Once the appropriate segment is identified, the data sender MUST mark
it as lost and SHOULD retransmit a SMSS starting from NACK sequence
number immediately, subject to congestion window and flow control
limits. If no unacknowledged segment covers the sequence number
provided in the NACK (e.g., the segment has already been acknowledged
or the NACK was spurious), the data sender MUST ignore the NACK and
MUST NOT proceed to Section 5.2.
5.2. Entering Fast Recovery
If the sender successfully identifies and marks a segment as lost
based on a NACK, it MUST enter Fast Recovery (as defined in
[RFC5681]), provided it is not already in a recovery phase.
A trimmed packet is an explicit signal of network congestion and
packet loss. The data sender should anticipate that other packets
within the same flight may have also been trimmed or dropped, which
will be subsequently detected via additional NACKs, Duplicate ACKs,
or RACK-TLP [RFC8985] timer expirations. By entering Fast Recovery,
the data sender ensures that the congestion window is appropriately
updated just once for the entire loss episode, conforming to the
principle that losses, regardless of the detection mechanism,
constitute a unified indication of congestion.
6. DSCP Marking Strategy
This specification introduces the use of specific DSCP values to
manage trimming behavior:
* DSCP_TRIMMABLE: Applied by the sender to data packets eligible for
trimming.
Mazilu, et al. Expires 7 January 2027 [Page 7]
Internet-Draft TCP Trimming July 2026
* DSCP_TRIMMED: Applied by a network switch after removing a
packet's payload.
Ideally, network switches should utilize at least two queues per
port: a standard queue for DSCP_TRIMMABLE and regular traffic, and a
high-priority queue for DSCP_TRIMMED and other control packets.
Return Path DSCP for NACKs:
A critical consideration is the DSCP value applied to the return NACK
packets. These should ideally bypass standard data low priority
queue to reach the sender with minimal latency.
* Alternative 1 (DSCP_TRIMMED): NACKs could use DSCP_TRIMMED.
However, this requires demultiplexing at the sender to
differentiate incoming NACKs from inbound data packets that were
trimmed on the reverse path.
* Alternative 2 (DSCP_CONTROL): The optimal approach, echoing Ultra
Ethernet Transport protocols, is to map control packets to a
dedicated DSCP_CONTROL codepoint. NACKs, pure ACKs, and FINs can
utilize this to achieve improved latency.
* Alternative 3 (DSCP_TRIMMABLE): NACKs are sent with standard data
priority. This reduces the number of required DSCP values but
sacrifices the latency advantage needed for rapid fast-recovery.
7. Interaction with Existing Loss Detection Mechanisms
In a fully trimming-enabled network topology where every switch is
capable of packet trimming, heuristic mechanisms like DupAck and
RACK-TLP MAY be disabled. Packet Trimming naturally handles high
degrees of packet reordering without generating the false positive
retransmissions common to DupAck heuristics.
This extension is scoped to data center networks or similarly
controlled administrative domains where the path can be configured
for packet trimming. Outside such a trimming-enabled domain,
endpoints MUST NOT assume that the path supports trimming.
Consequently, DupAck and RACK-TLP MUST NOT be disabled in those
cases. Packet Trimming does not hinder their functionality and can
work cooperatively alongside these mechanisms.
Mazilu, et al. Expires 7 January 2027 [Page 8]
Internet-Draft TCP Trimming July 2026
7.1. Interaction with RACK-TLP
Upon receiving a NACK, the data sender enters Fast Retransmit,
retransmits the specified packet, and transitions to Fast Recovery.
In this state, RACK-TLP continues to monitor for lost packets. RACK-
TLP will not falsely retransmit the trimmed packet again because its
internal RACK timer (based on rack.RTT + rack.reo_wnd) will not have
expired for the newly retransmitted segment.
Scenario A: Mixed Drop and Trim Events
If a flight contains both dropped and trimmed packets, NACKs and
SACKs cooperatively recover the flight:
Event TCP DATA SENDER TCP DATA RECEIVER
_____ _________________________________________________________
1. Send P0, P1, P2, P3 -->
[P1 dropped by network]
[P2 trimmed by network]
<-- Receive P0, ACK 0
<-- Receive P2 (Trimmed),
NACK 2, ACK 0
<-- Receive P3, ACK 0, SACK 3
2. Receive ACK 0
Receive NACK 2, ACK 0
(NACK triggers immediate
retransmission of P2)
Retransmit P2 -->
<-- Receive P2, ACK 0,
SACK 2, 3
3. Receive ACK 0, SACK 2, 3
RACK-TLP timer expires
[Logic: Now() - P1_ts > RTT + reo_wnd?]
(Condition = YES)
Retransmit P1 -->
<-- Receive P1, ACK 3
Figure 4
Scenario B: Delayed NACK / Preemptive SACK
If a SACK arrives before a NACK, and the rack.RTT + rack.reo_wnd
threshold has not been met, no retransmission occurs. When the NACK
subsequently arrives, P2 is instantly recovered. The succeeding
ACK+SACK for P2 provides the necessary time-lapse evidence for RACK
to securely declare P1 lost and trigger its retransmission. This
Mazilu, et al. Expires 7 January 2027 [Page 9]
Internet-Draft TCP Trimming July 2026
improves the standard RACK-TLP behavior which would otherwise, in
this scenario, wait 2 RTTs for sending a TLP probe. By having the
NACK trigger a retransmission which would bring more SACK information
does the same thing as a TLP probe would do but faster, in only 1
RTT.
Event TCP DATA SENDER TCP DATA RECEIVER
_____ ____________________________________________________________
1. Send P0, P1, P2, P3 -->
[P1 dropped by network]
[P2 trimmed by network]
<-- Receive P0, ACK 0
<-- Receive P2 (Trimmed),
ACK 0, NACK 2
<-- Receive P3, ACK 0, SACK 3
2. Receive ACK 0
Receive ACK 0, SACK 3
[No retransmission yet:
Thresholds not met]
3. Receive NACK 2, ACK 0
(Immediate recovery of P2)
Retransmit P2 -->
<-- Receive P2, ACK 0, SACK 2
4. Receive ACK 0, SACK 2
(RACK: Since a later packet
P2 has been delivered, P1
is marked lost by time)
Retransmit P1 -->
<-- Receive P1, ACK 3
(All data now contiguous)
Figure 5
(Implementation Note: To prevent redundant retransmissions in edge
cases where a NACK arrives late but RACK has already retransmitted
the segment, implementations MAY enforce a rule where NACK-driven
retransmissions are ignored if the segment was already retransmitted
within the last min_RTT.)
Mazilu, et al. Expires 7 January 2027 [Page 10]
Internet-Draft TCP Trimming July 2026
8. Congestion Control Considerations
A trimmed packet is an explicit and authoritative indication of
network congestion: a switch removed the payload precisely because a
queue exceeded its threshold. A NACK therefore conveys both a loss
to be repaired and a congestion signal. A trimming sender MUST treat
the receipt of a NACK as an indication of congestion and reduce its
sending rate, as it would for a segment loss detected by other means
[RFC5681].
The precise magnitude of this reduction is left as future work.
Because trimming reports loss on a per-segment basis, a sender learns
the exact number of segments lost in a flight rather than merely
inferring that at least one was lost, which may permit a more
accurate response than a single multiplicative decrease per loss
episode. Defining and evaluating such a response is an open item;
this document requires only that the reaction to a NACK be no more
aggressive than the standard response to an equivalent inferred loss
[RFC5681].
A retransmission triggered by a NACK is ordinary TCP data: it MUST
remain subject to the congestion window and to the count of packets
in flight, and MUST NOT bypass these limits. If the congestion
window does not currently allow the retransmission, the
retransmission is sent once the window permits.
Because a NACK is generated only after a switch has actually removed
a payload, the corresponding loss is never spurious; a sender SHOULD
NOT undo a congestion-window reduction caused by a NACK. Reductions
caused by inference-based mechanisms that remain enabled follow their
own rules; see Section 7.
9. IANA Considerations
9.1. TCP Options
This document defines two new TCP options that require assignment
from the "TCP Option Kind Numbers" registry [RFC9293]. IANA is
requested to assign two values:
Mazilu, et al. Expires 7 January 2027 [Page 11]
Internet-Draft TCP Trimming July 2026
+======+========+====================+===============+
| Kind | Length | Meaning | Reference |
+======+========+====================+===============+
| TBD1 | 2 | Trimming Permitted | This document |
+------+--------+--------------------+---------------+
| TBD2 | 6 | Trimming NACK | This document |
+------+--------+--------------------+---------------+
Table 1
The option formats are specified in Section 3.1 and Section 3.2.
Prior to the assignment of permanent Kind values, experimental
deployments can carry these options using the shared experimental
option Kinds and an Experiment Identifier as described in [RFC6994].
9.2. Differentiated Services Codepoints
This document does not request any new assignments from the
Differentiated Services Field Codepoints registry. The trimmable,
trimmed, and control service classes used in this document (see
Section 6) are realized with existing Differentiated Services
codepoints [RFC2474] selected by local or domain policy. The names
DSCP_TRIMMABLE, DSCP_TRIMMED, and DSCP_CONTROL are placeholders for
those locally configured codepoints and do not denote new codepoint
assignments.
10. Security Considerations
The mechanisms in this document add a new control signal, the NACK,
and rely on Differentiated Services markings to convey trimming
events. Packet trimming is primarily intended for deployment within
a single administrative domain, such as a data center, where the path
is largely trusted. The analysis below also notes the residual risks
that apply when traffic crosses a less trusted path.
10.1. Forged NACK Injection
An attacker who can inject a TCP segment carrying a forged Trimming
NACK option for an existing connection can attempt to force the
sender to retransmit a segment, wasting bandwidth and provoking an
unwarranted reduction of the congestion window. Several factors
bound this attack:
* A NACK is acted upon only when it arrives on a segment that passes
the connection's normal demultiplexing checks. An off-path
attacker must therefore guess the connection's four-tuple, as for
any spoofed TCP segment.
Mazilu, et al. Expires 7 January 2027 [Page 12]
Internet-Draft TCP Trimming July 2026
* As required in Section 5.1, the sender MUST ignore a NACK whose
sequence number does not correspond to an outstanding
unacknowledged segment. A forged NACK is effective only for an
in-window sequence number, which confines the attack to the same
blind in-window space analyzed in [RFC5961].
* A retransmission provoked by a forged NACK carries only data the
receiver legitimately expects; it cannot cause the receiver to
accept incorrect data. The impact is limited to wasted bandwidth
and an unnecessary congestion-window reduction.
To bound the congestion impact, the response to a NACK SHOULD be no
larger than the response to an equivalent loss inferred by other
means, so that a forged NACK is no more damaging than a forged
duplicate acknowledgment. Implementations MAY additionally rate-
limit the retransmissions and congestion reactions driven by NACKs.
10.2. Risks of Bypassing the TCP Checksum
As described in Section 4.1, a receiver skips TCP checksum validation
for a trimmed packet. This weakens the end-to-end integrity check
for the header of that packet, so corruption of those header fields
may pass undetected. The consequences are bounded by the restricted
use the receiver makes of a trimmed packet. The receiver reads only
the connection four-tuple and the sequence number, and MUST NOT
deliver any payload from a trimmed packet to the application (see
Section 4.2).
Undetected corruption can have the following effects:
* Corrupted port numbers: If the source or destination port is
corrupted, the receiver may fail to find a matching connection
socket and discard the packet. If a false match occurs, the
receiver will issue a NACK for an unexpected sequence number,
which the sender will ignore unless that sequence number matches
an unacknowledged packet.
* Corrupted sequence number: If the sequence number is corrupted,
the receiver will issue a NACK for an incorrect sequence number.
As with a forged NACK, this is ignored unless it falls within the
outstanding window, and even then it can only cause a spurious
retransmission, which the receiver disambiguates with a Duplicate
SACK [RFC2883].
Mazilu, et al. Expires 7 January 2027 [Page 13]
Internet-Draft TCP Trimming July 2026
10.3. DSCP Remarking and Priority Abuse
This specification places control traffic, including NACKs, and
trimmed packets into higher-priority service classes than ordinary
trimmable data (see Section 6). Where traffic can cross a trust
boundary, this raises two DSCP-related concerns:
* Priority theft: an attacker that sets the control or trimmed-class
codepoint on its own traffic could obtain preferential queueing,
claiming an unfair share of capacity or degrading the latency of
legitimate control traffic.
* Trimming evasion: an attacker that clears the trimmable codepoint
on its flows could render them ineligible for trimming, escaping
the congestion response that trimming imposes and competing
unfairly with conforming flows.
Both are instances of the general Differentiated Services trust model
[RFC2474] [RFC2475]: DSCP markings arriving from outside a trust
boundary cannot be relied upon. A trimming-enabled domain MUST treat
its boundary as a trust boundary and police or re-mark the DSCP of
ingress traffic, so that the trimmable, trimmed, and control
codepoints carry their intended meaning only within the domain that
enforces them.
11. References
11.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/info/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/info/rfc8174>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
Mazilu, et al. Expires 7 January 2027 [Page 14]
Internet-Draft TCP Trimming July 2026
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>.
11.2. Informative References
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option
for TCP", RFC 2883, DOI 10.17487/RFC2883, July 2000,
<https://www.rfc-editor.org/info/rfc2883>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961,
DOI 10.17487/RFC5961, August 2010,
<https://www.rfc-editor.org/info/rfc5961>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011,
<https://www.rfc-editor.org/info/rfc6298>.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options",
RFC 6994, DOI 10.17487/RFC6994, August 2013,
<https://www.rfc-editor.org/info/rfc6994>.
[RFC8985] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The
RACK-TLP Loss Detection Algorithm for TCP", RFC 8985,
DOI 10.17487/RFC8985, February 2021,
<https://www.rfc-editor.org/info/rfc8985>.
[UEC-SPEC] Ultra Ethernet Consortium, "Ultra Ethernet Consortium
Specification 1.0", June 2025,
<https://ultraethernet.org/>.
Mazilu, et al. Expires 7 January 2027 [Page 15]
Internet-Draft TCP Trimming July 2026
Authors' Addresses
Flavius Romeo Mazilu
POLITEHNICA Bucharest
Email: flavius.mazilu@stud.acs.upb.ro
Valentin Ionut Bobaru
POLITEHNICA Bucharest
Email: valentin.bobaru@stud.acs.upb.ro
Costin Raiciu
POLITEHNICA Bucharest / Broadcom Inc.
Email: costin.raiciu@upb.ro
Mazilu, et al. Expires 7 January 2027 [Page 16]