| Internet-Draft | TCP Trimming | November 2026 |
| Mazilu, et al. | Expires 6 May 2027 | [Page] |
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.¶
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 6 May 2027.¶
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 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.¶
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.¶
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].¶
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.¶
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.¶
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.¶
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 Section 6. 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:¶
+----------+----------+---------------------------+
| Kind=TBD | Length=7 | DSCP Profile (5 bytes) |
+----------+----------+---------------------------+
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:¶
profile = ((DSCP_TRIMMABLE & 0x3F) << 30) |
((DSCP_TRIMMED & 0x3F) << 24) |
((DSCP_CONTROL & 0x3F) << 18) |
((DSCP_NO_TRIM & 0x3F) << 12) |
((DSCP_TRIMMABLE_RETX & 0x3F) << 6) |
((DSCP_TRIMMED_LASTHOP & 0x3F) << 0);
/* profile is written as 5 bytes in network byte order */
¶
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.¶
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 [RFC2018]); there is not any requirement for NACK to be the only option set.¶
Trimming NACK Option Format:¶
+----------+----------+-------------------------+
| Kind=TBD | Length=6 | NACK Sequence (4 bytes) |
+----------+----------+-------------------------+
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
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.¶
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.¶
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 Section 3.5. Security considerations for bypassing checksum validation are discussed in Section 11.3.¶
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.¶
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.¶
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.¶
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.¶
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.¶
This specification uses six DSCP categories, following the naming and semantics defined in the Ultra Ethernet Consortium specifications [UEC-SPEC]:¶
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 Section 3.2 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.¶
The Trimming Permitted option MAY be carried in SYN and SYN+ACK packets that also carry TCP Fast Open [RFC7413] 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.¶
When TCP-AO [RFC5925] 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.¶
When MPTCP [RFC8684] 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.¶
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.¶
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
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.¶
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)
(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.)¶
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 8.¶
This document defines one new TCP option that requires assignment from the "TCP Option Kind Numbers" registry [RFC9293]. 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 Section 3.2 and Section 3.3. 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 [RFC6994].¶
This document does not request any new assignments from the Differentiated Services Field Codepoints registry. The DSCP categories 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, 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.¶
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.¶
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 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.¶
When TCP-AO [RFC5925] 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.¶
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].¶
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.¶