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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . [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, . 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, . 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, . [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, . [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, . [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, . [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, . [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, . [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013, . [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, . [UEC-SPEC] Ultra Ethernet Consortium, "Ultra Ethernet Consortium Specification 1.0", June 2025, . 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]