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.

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 . TCP Trimming Permitted Option Format:

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 ); 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

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 . 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 NACK TCP option. 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

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 introduces the use of specific DSCP values to manage trimming behavior:

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.

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.

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 two new TCP options that require assignment from the "TCP Option Kind Numbers" registry . IANA is requested to assign two values:

Kind	Length	Meaning	Reference
TBD1	2	Trimming Permitted	This document
TBD2	6	Trimming NACK	This document

The option formats are specified in and . 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 .

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 ) are realized with existing Differentiated Services codepoints 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.

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.

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.