TCP Packet Trimming Extension

Introduction TCP's congestion control relies primarily on packet loss as a signal of congestion, or Explicit Congestion Notification (ECN) as a proactive measure. The accuracy and speed of these signals are vital for a mechanism to adapt quickly and utilize available bandwidth efficiently. It is widely recognized that falling back to a Retransmission Timeout (RTO) 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 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 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 , 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 , 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 .

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 when, and only when, they appear in all capitals, as shown here.

TCP Extensions for Packet Trimming All additional state and signaling required between the two communicating hosts are carried as TCP options. This document defines a single TCP option, the TCP Trimming option, that is used for both capability negotiation and NACK signaling. The meaning of the option is inferred from its length and from the phase of the connection in which it appears.

TCP Trimming Option The TCP Trimming option uses a single TCP option Kind. Two lengths are defined:

Length=7: Trimming Permitted, exchanged only during the three-way handshake. It carries a DSCP profile that the two endpoints use to negotiate the DSCP values used for trimming.
Length=6: Trimming NACK, exchanged only on packets sent after the connection is established. It carries the sequence number of the trimmed packet.

A receiver MUST ignore a TCP Trimming option whose length is not 6 or 7. A receiver MUST ignore a Length=7 option on a non-SYN packet and MUST ignore a Length=6 option on a SYN packet.

Capability Negotiation (Trimming Permitted) If both endpoints support packet trimming, they SHOULD set the DSCP_TRIMMABLE codepoint on data packets once negotiation is complete. To prevent a scenario where a sender marks packets as trimmable but the receiver does not recognize the corresponding trimmed or control codepoints, capability negotiation is required. A TCP Trimming option with Length=7, Trimming Permitted, MUST be exchanged during the three-way handshake. Only if both the SYN and SYN+ACK packets carry an identical Trimming Permitted option will subsequent data packets be considered trimmable. This option MUST NOT be set on non-SYN packets. The Trimming Permitted option carries a DSCP profile that contains the six DSCP values defined in . The profile allows each endpoint to verify that the peer uses the same codepoints, avoiding silent failures caused by mismatched local DSCP configuration. TCP Trimming Permitted Option Format:

The DSCP Profile is a 36-bit big-endian value, padded with 4 reserved bits in the most-significant nibble of the first profile byte. The six DSCP values are packed as follows: If the local configuration does not provide an explicit value for an optional DSCP category, the endpoint infers it as follows:

DSCP_CONTROL defaults to DSCP_TRIMMABLE.
DSCP_NO_TRIM defaults to 0 (CS0/DF).
DSCP_TRIMMABLE_RETX defaults to DSCP_TRIMMABLE.
DSCP_TRIMMED_LASTHOP defaults to DSCP_TRIMMED.

Trimming is enabled only when the Trimming Permitted option received from the peer exactly matches the option sent by the endpoint. If the options differ in any bit, both endpoints MUST disable trimming for the connection. This DSCP negotiation mechanism also creates a foundation for extending packet trimming across multiple administrative domains, or even across the public Internet, provided that domain-border devices translate DSCP values and rewrite the DSCP values carried in the Trimming Permitted option so that both endpoints agree on a consistent set of codepoints end-to-end. Defining such translation behavior is outside the scope of this document and is left for future work.

Trimming NACK Option When congestion occurs at a network switch along the path, the switch trims the payload of packets marked with a DSCP_TRIMMABLE value. The switch updates the IP header to the corresponding DSCP_TRIMMED or DSCP_TRIMMED_LASTHOP value according to the domain's configured mapping between trimmable and trimmed codepoints, and forwards the header to the data receiver. The handshake ensures that both endpoints agree on the values used in this mapping. Upon receiving a packet, the data receiver inspects the DSCP field. If the packet is marked with the exact negotiated DSCP_TRIMMED or DSCP_TRIMMED_LASTHOP value, the receiver MUST immediately issue a new TCP packet with no data payload, carrying a TCP Trimming option with Length=6 (Trimming NACK). This option contains the sequence number of the trimmed packet. The receiver MAY include other options in this packet (e.g., SACK blocks ); there is not any requirement for NACK to be the only option set. Trimming NACK Option Format:

Basic Trimming Packet Flow The following diagram illustrates the flow of packets when congestion occurs and a packet is trimmed:

[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 ]]>

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

Data Receiver Behavior upon Receiving a Trimmed Packet An endpoint MUST recognize only the exact DSCP values negotiated in the Trimming Permitted option. A packet whose DSCP field does not exactly match one of the negotiated values MUST be processed as ordinary TCP traffic, even if the DSCP value would belong to a trimming-related category in another deployment.

Bypassing TCP Checksum Validation When a TCP data receiver identifies a trimmed packet by observing the exact negotiated DSCP_TRIMMED or DSCP_TRIMMED_LASTHOP value 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 . Security considerations for bypassing checksum validation are discussed in .

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.

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 TCP Trimming option with Length=6 (Trimming NACK). The NACK option payload is 4 bytes in length and MUST contain the sequence number extracted from the received trimmed packet.

Data Sender Behavior upon Receiving a NACK The data sender MUST mark trimmable data packets with the exact negotiated DSCP_TRIMMABLE value (or DSCP_TRIMMABLE_RETX when used). NACKs SHOULD arrive with the exact negotiated DSCP_CONTROL value.

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 .

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 ), 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 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.

DSCP Marking Strategy This specification uses six DSCP categories, following the naming and semantics defined in the Ultra Ethernet Consortium specifications :

DSCP_TRIMMABLE: Applied by the sender to data packets eligible for trimming.
DSCP_TRIMMED: Applied by a network switch after removing a packet's payload.
DSCP_CONTROL: MAY be applied by endpoints to control traffic, including NACKs.
DSCP_NO_TRIM: MAY be applied to packets that must not be trimmed.
DSCP_TRIMMABLE_RETX: MAY be applied to retransmitted data packets to reduce the probability that they are trimmed.
DSCP_TRIMMED_LASTHOP: MAY be applied by the last-hop switch when trimming occurs at the final network hop.

DSCP_TRIMMABLE and DSCP_TRIMMED are required for trimming. The other four categories are optional; when they are not configured, the defaults specified in apply. All six values are negotiated using the Trimming Permitted option. Endpoints and switches MUST use only the exact negotiated values when marking or recognizing trimming-related traffic. A packet carrying any other DSCP value MUST NOT be treated as trimmable, trimmed, or trimming control traffic. 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 the 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.

Interactions with Other TCP Extensions

TCP Fast Open The Trimming Permitted option MAY be carried in SYN and SYN+ACK packets that also carry TCP Fast Open data or cookie requests. Because trimming is negotiated during the three-way handshake, SYN and SYN+ACK packets are sent before the endpoints have agreed to use trimming; therefore, any data carried in a SYN or SYN+ACK MUST use the connection's default DSCP and MUST NOT be marked DSCP_TRIMMABLE.

TCP Authentication Option (TCP-AO) When TCP-AO is used, a trimmed data packet cannot be authenticated because the switch removes payload bytes that are covered by the TCP-AO authentication tag. An attacker that can inject DSCP_TRIMMED packets toward a receiver may cause the receiver to emit NACKs to a spoofed source. Those NACKs may themselves be authenticated by TCP-AO, so the victim source receives apparently valid NACKs and reduces its sending rate. Because the trigger packet could not be authenticated, TCP-AO does not protect against this attack. Implementations that require full TCP-AO authentication of every data packet MUST NOT use packet trimming, or MUST rate-limit reactions to NACKs.

Multipath TCP (MPTCP) When MPTCP is used, the TCP Trimming option and the DSCP profile are negotiated independently on each subflow. A trimming event on one subflow affects only the sequence space and congestion state of that subflow; it does not imply loss on other subflows. An MPTCP sender MUST treat a NACK received on a subflow as a loss signal for that subflow only and MUST NOT use it to infer loss across the whole MPTCP connection.

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.

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:

[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 ]]> 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 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.

[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) ]]> (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.)

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

IANA Considerations

TCP Options This document defines one new TCP option that requires assignment from the "TCP Option Kind Numbers" registry . IANA is requested to assign one value:

Kind	Length	Meaning	Reference
TBD	7	Trimming Permitted	This document
TBD	6	Trimming NACK	This document

The option formats are specified in and . Prior to the assignment of a permanent Kind value, experimental deployments can carry these options using the shared experimental option Kinds and an Experiment Identifier as described in .

Differentiated Services Codepoints This document does not request any new assignments from the Differentiated Services Field Codepoints registry. The DSCP categories used in this document (see ) are realized with existing Differentiated Services codepoints selected by local or domain policy. The names DSCP_TRIMMABLE, DSCP_TRIMMED, DSCP_CONTROL, DSCP_NO_TRIM, DSCP_TRIMMABLE_RETX, and DSCP_TRIMMED_LASTHOP are placeholders for those locally configured codepoints and do not denote new codepoint assignments.

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.

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.
As required in , 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 .
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.

TCP-AO and Trimmed Packets When TCP-AO is in use, a trimmed data packet can no longer be authenticated because the authentication tag covers payload bytes that the switch has removed. An attacker that can inject DSCP_TRIMMED packets toward a receiver may cause the receiver to emit NACKs to a spoofed source. Those NACKs may be authenticated by TCP-AO, so the victim source receives apparently valid NACKs and reduces its sending rate. Thus, trimming weakens TCP-AO's protection against spoofed loss signals. Deployments that require full TCP-AO authentication for every data packet MUST NOT use packet trimming, or MUST treat the congestion reaction to NACKs as untrusted and rate-limit it.

Risks of Bypassing the TCP Checksum As described in , 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 ). 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 .

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 ). 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 : 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.