Network Working Group Z. Li Internet-Draft Z. Du Intended status: Standards Track China Mobile Expires: 6 May 2027 J. Wang W. Cheng Y. Zhao Centec C. Zhao SAIA X. Sun Inesa 2 November 2026 Congestion-Aware Reliability Enhancement Mechanism (CREM) for RDMA over IP Networks draft-li-rdma-crem-00 Abstract RDMA transports designed for lossless data center fabrics perform poorly over long-distance, high bandwidth-delay product, or lossy IP paths: go-back-N retransmission resends whole windows, selective repeat costs at least a round trip per loss, and fixed forward erasure correction wastes capacity when the path is clean. This document specifies the Congestion-Aware Reliability Enhancement Mechanism (CREM), which protects datagram-based RDMA flows without modifying their packets. CREM adds a UDP-encapsulated repair channel on which the sender transmits erasure-coded repair symbols computed over blocks of RDMA packets, adapts the redundancy to measured loss and to whether losses are caused by congestion, and recovers losses that exceed the redundancy with a coded retransmission: a number of repair symbols, computed only over the lost packets, that is smaller than the number of lost packets. Per-packet retransmission remains as the final fallback. Optional path reports from on-path nodes, derived from Alternate Marking measurements or from the nodes' own drops, inform the adaptation. 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/. Li, et al. Expires 6 May 2027 [Page 1] Internet-Draft CREM for RDMA November 2026 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 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Overview of CREM . . . . . . . . . . . . . . . . . . . . 4 1.3. Scope and Applicability . . . . . . . . . . . . . . . . . 4 1.4. Relationship to Other Work . . . . . . . . . . . . . . . 5 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Source Blocks and Coding . . . . . . . . . . . . . . . . . . 7 4.1. Source Symbols . . . . . . . . . . . . . . . . . . . . . 7 4.2. Source Blocks . . . . . . . . . . . . . . . . . . . . . . 7 4.3. FEC Schemes . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. Scheme 0: Source Copy . . . . . . . . . . . . . . . . 8 4.3.2. Scheme 1: Cauchy Reed-Solomon over GF(2^8) . . . . . 8 4.3.3. Scheme 2: XOR Parity . . . . . . . . . . . . . . . . 9 5. Adaptive Forward Erasure Correction . . . . . . . . . . . . . 9 5.1. Capability Negotiation . . . . . . . . . . . . . . . . . 9 5.2. Parameter Synchronization . . . . . . . . . . . . . . . . 9 5.3. Redundancy Policy . . . . . . . . . . . . . . . . . . . . 10 5.4. Sending Repair Symbols . . . . . . . . . . . . . . . . . 11 6. Receiver Operation . . . . . . . . . . . . . . . . . . . . . 11 7. Coded Retransmission . . . . . . . . . . . . . . . . . . . . 11 7.1. Repair Request . . . . . . . . . . . . . . . . . . . . . 12 7.2. Coded Response . . . . . . . . . . . . . . . . . . . . . 12 7.3. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Congestion-Aware Path Feedback . . . . . . . . . . . . . . . 13 Li, et al. Expires 6 May 2027 [Page 2] Internet-Draft CREM for RDMA November 2026 8.1. Receiver Loss Reports . . . . . . . . . . . . . . . . . . 13 8.2. On-Path Path Reports . . . . . . . . . . . . . . . . . . 13 9. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 14 9.2. REPAIR . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.3. HELLO and HELLO_ACK . . . . . . . . . . . . . . . . . . . 15 9.4. PARAM_UPDATE and PARAM_ACK . . . . . . . . . . . . . . . 16 9.5. REPAIR_REQUEST . . . . . . . . . . . . . . . . . . . . . 17 9.6. LOSS_REPORT . . . . . . . . . . . . . . . . . . . . . . . 17 9.7. PATH_REPORT . . . . . . . . . . . . . . . . . . . . . . . 17 9.8. CLOSE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Congestion Control Considerations . . . . . . . . . . . . . . 19 11. Operational Considerations . . . . . . . . . . . . . . . . . 19 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 13.1. CREM Registries . . . . . . . . . . . . . . . . . . . . 20 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 14.1. Normative References . . . . . . . . . . . . . . . . . . 21 14.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Coding Example . . . . . . . . . . . . . . . . . . . 24 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction 1.1. Background RDMA has become the dominant transport for training, inference, and storage traffic inside AI data centers. Deployments now extend RDMA across data centers and metropolitan or wide-area links, for example to move key-value caches between inference sites or to synchronize training across sites [I-D.li-tsvwg-inference-transport]. These paths have round-trip times of milliseconds rather than microseconds, carry several megabytes of data per round trip, and are not lossless. Reliability mechanisms behave very differently on such paths: * Go-back-N retransmission, the classic behavior of RDMA reliable connections, resends every packet after a loss. A single loss on a high-BDP path wastes up to a full window. * Selective repeat, using SACK or NACK, resends only lost packets but adds at least one round trip of latency per loss event and requires per-packet state. * Forward erasure correction (FEC) sends redundancy in advance and recovers losses without waiting, but a fixed redundancy level either wastes capacity on clean paths or fails on bad ones. Li, et al. Expires 6 May 2027 [Page 3] Internet-Draft CREM for RDMA November 2026 Which mechanism performs best depends on message size, loss rate, and round-trip time, and these change over time. No interoperable mechanism today combines the strengths of retransmission and redundancy for RDMA over IP and adapts between them. 1.2. Overview of CREM CREM has three cooperating parts: 1. Adaptive forward erasure correction (Section 5): the sender groups the packets of an RDMA flow into source blocks of k consecutive packet sequence number positions and sends m repair symbols per block on a separate UDP flow. The pair (k, m) is negotiated and changed over a reliable control exchange as the observed loss changes. 2. Coded retransmission (Section 7): when a block has lost more packets than its repair symbols can recover, the receiver requests repair, listing the lost packets. The sender answers with new repair symbols computed over the lost packets only; their number is the number of lost packets minus the repair symbols the receiver already holds. If that also fails, CREM falls back to per-packet retransmission. 3. Congestion-aware path feedback (Section 8): receivers report loss and ECN statistics, and on-path nodes optionally report per-hop loss and delay measured with Alternate Marking [RFC9341], as well as packets they dropped. The sender uses this to tell congestion loss from transmission loss: redundancy is increased for the latter but not for the former, where it would add to the congestion. CREM does not change RDMA packets, RDMA transport semantics, or congestion control. Repair traffic is rate-limited and reacts to congestion as specified in Section 10. 1.3. Scope and Applicability This document specifies CREM for RDMA transports that carry each packet in a UDP datagram and number packets with a packet sequence number (PSN), with RDMA over Converged Ethernet version 2 (RoCEv2) [IBTA-ROCEV2] as the defined flow kind. CREM only reads the PSN and the destination queue pair of protected packets. RDMA transports over TCP, such as RDMAP [RFC5040] with MPA [RFC5044], are reliable at the TCP layer and do not need CREM. Li, et al. Expires 6 May 2027 [Page 4] Internet-Draft CREM for RDMA November 2026 CREM is intended for limited domains [RFC8799], such as interconnected data centers of one operator. The CREM sender and receiver functions can be implemented in the RDMA NIC, in a host shim, or in a gateway at the boundary of a long-distance segment that protects all RDMA flows crossing it. 1.4. Relationship to Other Work The FEC Framework (FECFRAME) [RFC6363] defines how FEC schemes protect arbitrary packet flows; CREM follows its model of source blocks and repair flows and uses its construction of source symbols from packets, but adds adaptive parameters, coded retransmission, and RDMA-specific source identification. [I-D.ietf-dtn-btpu-fec] applies FECFRAME to bundle transfer; [I-D.michel-quic-fec] and [I-D.dmoskvitin-quic-adaptive-fec] add FEC to QUIC. [I-D.chen-rdma-windowless-ack] extends acknowledgments inside the RDMA transport header; CREM leaves transport headers unchanged and can coexist with it. [I-D.hzh-fantel-wan-tunnel] and [I-D.sang-fann-fast-network-event-notification] address fast network notifications for RDMA and AI traffic; the path reports of CREM are specific to repair decisions and could be carried by a general notification mechanism when one is standardized. [I-D.liu-opsawg-alt-mark-per-packet] discusses loss localization with Alternate Marking. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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. Protected flow: The packets of one RDMA connection in one direction, for example all RoCEv2 packets toward one destination queue pair. CREM Sender Function (CSF), CREM Receiver Function (CRF): The functions at the two ends of a protected flow that implement this document. Source packet: A packet of the protected flow, unchanged by CREM. Source block: k source packets with consecutive PSNs, starting at the Block Start PSN. Source symbol: The octet string derived from a source packet for coding (Section 4.1). Li, et al. Expires 6 May 2027 [Page 5] Internet-Draft CREM for RDMA November 2026 Repair symbol: A coded combination of source symbols, carried in a REPAIR message. Repair Index: The identifier i of a repair symbol within its block. Coded retransmission: Repair symbols sent in response to a repair request and computed over the lost source symbols only. Repair Session ID: An identifier that links a coded retransmission to the request that triggered it. Path Reporter: An on-path node that implements Section 8.2. 3. Architecture +----------+ source packets (unchanged) +----------+ +----------+ | RDMA |--------------------------->| |->| RDMA | | sender | | Path | | receiver | +----------+ | Reporter | +-----^----+ | CSF |--- REPAIR (CREM port) ---->| (option) |->| CRF | +----------+ +----------+ +----------+ restored packets go to the RDMA receiver via the CRF CREM messages (UDP, CREM port): CSF -> CRF : HELLO, PARAM_UPDATE, REPAIR, CLOSE CRF -> CSF : HELLO_ACK, PARAM_ACK, LOSS_REPORT, REPAIR_REQUEST, CLOSE Reporter -> CSF : PATH_REPORT Figure 1: CREM Functions and Message Paths The CSF observes the protected flow as the RDMA sender emits it, forms source blocks, and sends repair symbols. The CRF observes the protected flow as it arrives, holds the source symbols of incomplete blocks, decodes when possible, and passes restored packets to the RDMA receiver as if they had arrived from the network. All CREM messages use UDP [RFC768] with the CREM port as destination port. The CREM port is a UDP port configured by the operator of the limited domain; this document does not request a port assignment from the "Service Name and Transport Protocol Port Number Registry" [RFC6335]. All CSFs, CRFs, and Path Reporters of a domain MUST be configured with the same CREM port, because Path Reporters send to CSFs without prior signaling. Operators SHOULD choose the port from the Dynamic Ports range (49152-65535) and MUST ensure that no other service of the domain uses it. Implementations MUST NOT assume a default port value. Li, et al. Expires 6 May 2027 [Page 6] Internet-Draft CREM for RDMA November 2026 4. Source Blocks and Coding 4.1. Source Symbols For a source packet whose UDP payload is the octet string P (for RoCEv2, from the Base Transport Header through the invariant CRC), the source symbol is: S = uint16(len(P)) || P || zero padding to T octets where T, the symbol length, is at least the largest UDP payload of the flow plus 2. This follows the construction of application data unit information in [RFC6363] without the flow identifier octet, which CREM conveys in the message header. The length prefix lets the CRF restore P exactly. 4.2. Source Blocks A source block covers k consecutive PSN positions, starting at the Block Start PSN; position j (0 <= j < k) corresponds to PSN Block Start PSN + j, modulo 2^24. Blocks of a flow do not overlap. Not every PSN position carries a packet in the protected direction: for example, an RDMA READ request consumes one PSN for each expected response packet, and those PSNs never appear in the request direction. The CSF therefore records which positions of a block carry a source packet in a Present Bitmap, which it sends in every REPAIR message of the block. Absent positions are neither coded nor expected; they are treated as zero symbols that are known to both sides. Only packets that carry a new PSN are sources; acknowledgment and negative acknowledgment packets are not protected. A source packet that the RDMA transport retransmits with the same PSN occupies the same position. Retransmitted packets are expected to be identical to the original; restored packets are verified as described in Section 6, so a difference is detected rather than delivered. The CSF closes a block when k positions have been covered, or earlier at the end of a burst; the k of a closed block is carried in its REPAIR messages. When the CRF has received no REPAIR message for a block, it does not know its boundaries and reports losses by PSN range instead (Section 7.1). Li, et al. Expires 6 May 2027 [Page 7] Internet-Draft CREM for RDMA November 2026 The CRF does not need REPAIR messages to recognize the most common absent positions: when it observes an RDMA READ request, it derives the number of PSNs the request consumes from its DMA Length and the RDMA MTU announced in HELLO, and treats those PSNs as absent. If the CSF receives a PSN-range request that names absent positions, it answers with an INFO message: a REPAIR with the INFO flag, Symbol Length zero, and no symbol, which carries the Block Start PSN, k, and Present Bitmap of the block. 4.3. FEC Schemes FEC schemes are identified by an 8-bit value (Section 13). Support for scheme 1 is REQUIRED. 4.3.1. Scheme 0: Source Copy The repair symbol with Repair Index i is source symbol i of the block, unmodified. It is used for per-packet retransmission by the CSF (Section 7.3). 4.3.2. Scheme 1: Cauchy Reed-Solomon over GF(2^8) Arithmetic is in GF(2^8) defined by the primitive polynomial x^8 + x^4 + x^3 + x^2 + 1 (0x11D); addition is bitwise exclusive-or. For source index j and Repair Index i, define y_j = j and x_i = 255 - i, and the coefficient C(i, j) = 1 / (x_i + y_j) (computed in GF(2^8)) which exists whenever i + j < 255. The CSF MUST use only Repair Indices with i + k <= 255. A repair symbol over a set L of source indices is, octet by octet: R_i[L] = sum over j in L of C(i, j) * S_j Li, et al. Expires 6 May 2027 [Page 8] Internet-Draft CREM for RDMA November 2026 An ordinary repair symbol uses L equal to all present positions of the block. A coded retransmission uses L equal to the set of lost sources named in the request (Section 7). Because every square submatrix of a Cauchy matrix is non-singular, the receiver can solve for any set U of u unknown source symbols from any u repair symbols of distinct indices whose sets L all contain U, after subtracting the contributions of the source symbols it holds. Ordinary repair symbols always satisfy this condition. A coded retransmission satisfies it because its L is the CRF's set of unknown sources at the time of the request, and that set only shrinks afterwards. Repair symbols generated without a request from the CRF (Section 8.2) MUST therefore be ordinary repair symbols. Under these rules the code is maximum distance separable: as many symbols as there are present sources recover the block. 4.3.3. Scheme 2: XOR Parity The single repair symbol (m = 1, Repair Index 0) is the bitwise exclusive-or of all source symbols of the block. It recovers one lost source. Coded retransmission is not defined for this scheme; blocks with more than one loss use the fallback of Section 7.3. 5. Adaptive Forward Erasure Correction 5.1. Capability Negotiation Before protecting a flow, the CSF sends HELLO to the CRF, giving the flow descriptor, the schemes it supports, and its limits for k, m, and T. The CRF answers with HELLO_ACK, which assigns the Flow ID used in all later messages for the flow and states the CRF's limits, including the number of blocks it can hold concurrently. The CRF MUST choose the Flow ID at random among unused values. The CSF retransmits HELLO with exponential backoff, starting at 1 ms, for at most eight attempts; without an answer it does not protect the flow. The effective limits are the minimum of the two sides. The CSF sends all later messages of the flow to the address and port from which HELLO_ACK came, and the CRF sends to the address and port from which HELLO came. 5.2. Parameter Synchronization Each configuration (scheme, k, m, T) has a Config ID. To change the configuration, the CSF sends PARAM_UPDATE with a new Config ID and an Effective PSN. It retransmits PARAM_UPDATE after a retransmission timeout (initially 2 * SRTT, at least 1 ms), doubling the timeout on each retransmission, until it receives PARAM_ACK for that Config ID; after eight unanswered attempts it sends CLOSE. The CSF MUST NOT use the new configuration for blocks that start before the Effective PSN Li, et al. Expires 6 May 2027 [Page 9] Internet-Draft CREM for RDMA November 2026 or before PARAM_ACK has been received. If the Effective PSN passes before the acknowledgment arrives, the CSF continues with the old configuration and sends PARAM_UPDATE again with a later Effective PSN. Every REPAIR message carries its Config ID, scheme, and k, so that the CRF never decodes a block with the wrong parameters. The CRF reserves decoding resources when it acknowledges a configuration and MUST accept REPAIR messages for any configuration it has acknowledged and not yet released. A configuration is released when a newer configuration has been acknowledged and every block that uses the older one has been closed or has fallen back. 5.3. Redundancy Policy The redundancy policy is local to the CSF, subject to the following requirements: * The CSF MUST classify recent losses as congestion-related or not, using the evidence of Section 8: rising ECN Congestion Experienced marks [RFC3168], growth of queueing delay reported for a hop, and drops reported by a node as queue overflow indicate congestion; losses without these signals are treated as transmission losses. * The CSF MUST NOT increase m in response to congestion-related loss beyond a configured m_cong (RECOMMENDED: 1). Redundancy does not help a congested queue and adds load to it. * The CSF MUST apply hysteresis: it MUST NOT change the configuration more than once per two smoothed round-trip times, because a change takes effect only after a round trip. The RECOMMENDED policy for transmission loss uses an estimate p of the packet loss rate (an exponentially weighted moving average over LOSS_REPORT intervals) and chooses the smallest m for which the probability that a block of k + m packets loses more than m packets, under independent losses with rate p, is below a target epsilon (default 10^-4). m = 0 is chosen when p is so low that coded retransmission alone meets the target; the flow then incurs no redundancy overhead and still benefits from coded retransmission. The block size k trades decoding delay (the CRF waits for up to k packets) against overhead; k = 32 is a reasonable default for multi- millisecond paths. Li, et al. Expires 6 May 2027 [Page 10] Internet-Draft CREM for RDMA November 2026 5.4. Sending Repair Symbols The CSF sends the m repair symbols of a block, with Repair Indices 0 to m-1, as soon as the block is closed. It MAY spread them among the next source packets to reduce burstiness. Repair messages are subject to the rate limits of Section 10. 6. Receiver Operation For each open block, the CRF records the source symbols and repair symbols received. The following rules apply: * When the number of distinct symbols received for a block reaches the number of present positions, the CRF decodes the missing source symbols and restores the packets. It MUST verify the invariant CRC of each restored RoCEv2 packet [IBTA-ROCEV2] and discard a packet that fails; it then requests a fallback for that position (Section 7.3). Verified packets are passed to the RDMA receiver, and the block is closed. * The CRF MAY hold source packets with PSNs after a gap for up to a hold time H (RECOMMENDED: the time to receive one block at the flow rate, at most one quarter of the minimum RTT), so that restored packets reach the RDMA receiver in order. When H expires, it MUST release held packets in PSN order even if the gap remains, so that CREM never delays the RDMA transport's own recovery by more than H. * Packets restored after their successors were released are still passed to the RDMA receiver; RDMA transports discard duplicates and accept late packets according to their own rules. * A block is incomplete when, after the CRF has observed a packet beyond the block or all of its repair symbols, plus a reordering allowance (RECOMMENDED: H), it holds fewer symbols than present positions. The CRF then proceeds as in Section 7. A PSN gap for which the CRF has seen no REPAIR message is handled in the same way, using the PSN-range form of the request. Restored packets carry no ECN marking. The CRF counts them separately so that they do not mask losses in its LOSS_REPORT. 7. Coded Retransmission Li, et al. Expires 6 May 2027 [Page 11] Internet-Draft CREM for RDMA November 2026 7.1. Repair Request For an incomplete block, the CRF sends REPAIR_REQUEST with the Block Start PSN, k, the Config ID, a bitmap of the lost source indices (the set L, with X = |L| lost sources), the number r of repair symbols it holds for the block, and a suggested count M_s = X - r + delta, where delta (RECOMMENDED: 0 on clean paths, 1 when p exceeds one percent) allows for the loss of repair symbols; M_s MUST NOT exceed X. The final decision on M rests with the CSF. A Request ID distinguishes successive requests for the same block. When the CRF has received no REPAIR message for the affected positions, it does not know the block structure and sends the PSN- range form instead: a list of lost PSN ranges, each a start PSN and a count. This list of lost PSNs is all the CSF needs: it maps the PSNs to its blocks and answers each block as below, with r taken as zero. 7.2. Coded Response On receiving REPAIR_REQUEST for a block it still holds, the CSF: 1. chooses M with X - r <= M <= X, normally M = M_s; 2. computes M repair symbols R_i[L] over the lost set L, using Repair Indices not previously used for the block; if fewer than M unused indices with i + k <= 255 remain, it answers with Source Copy symbols instead (Section 7.3); 3. sends them in REPAIR messages with the RETX flag set, the lost- set bitmap, and a Repair Session ID equal to the Request ID; and 4. sends them back to back, so that the whole repair takes one round trip regardless of X. Because M is X - r (plus delta), coded retransmission sends fewer symbols than the number of lost packets whenever the receiver holds at least one repair symbol of the block, and it recovers all lost packets within one round trip. The CSF MUST keep the source symbols of a block until the block is acknowledged by the RDMA transport or until it gives up retransmission for the block. It MUST respond to at most one request per block per smoothed round-trip time. The CRF decodes when the ordinary and retransmitted repair symbols it holds, together with its source symbols, number at least the present positions of the block. If source packets in L arrive late, the CRF subtracts their contribution from the retransmitted symbols as well. Li, et al. Expires 6 May 2027 [Page 12] Internet-Draft CREM for RDMA November 2026 7.3. Fallback A block that remains incomplete after two coded retransmission rounds, or whose scheme does not support coded retransmission, falls back to per-packet retransmission. Either: * the CSF sends the lost source symbols with scheme 0 (Source Copy) in response to a REPAIR_REQUEST carrying the FALLBACK flag; or * the CRF releases all held packets of the block and leaves recovery to the RDMA transport's own retransmission. In both cases the data is eventually delivered by the RDMA transport's reliability, which CREM never disables. 8. Congestion-Aware Path Feedback 8.1. Receiver Loss Reports The CRF sends LOSS_REPORT at least once per smoothed round-trip time while the flow is active. It reports, for the interval: source packets expected and received (before restoration), packets restored by decoding, blocks incomplete after the first decoding attempt, ECN CE marks observed on source packets, REPAIR messages received, CE marks observed on REPAIR messages, and the interval duration. The CSF derives the path loss rate p and the CE fractions from it. 8.2. On-Path Path Reports Support for this section is OPTIONAL for network nodes; CSFs MUST be able to process PATH_REPORT. A Path Reporter that measures the protected flow with Alternate Marking ([RFC9341], [RFC9342], applied to IPv6 with [RFC9343]) can determine, per marking period, how many packets of the flow were lost between measurement points and how its queueing delay changed. A node also knows exactly which packets it dropped itself, for example because of queue overflow or a corrupted frame. A Path Reporter MAY send PATH_REPORT to the source address of the protected flow, containing one Hop Entry per measurement point with: * the node identifier and the marking period number; * the number of packets lost in the period; * the change in queueing delay in microseconds, signed; Li, et al. Expires 6 May 2027 [Page 13] Internet-Draft CREM for RDMA November 2026 * a cause code: 1 for queue overflow, 2 for transmission error, 0 for unknown; and * optionally, the PSNs of packets the node dropped itself. A CSF that receives PSNs dropped by a node MAY send additional ordinary repair symbols for the affected blocks without waiting for the CRF's request (Section 4.3.2). This saves the time between the drop and the receiver's detection of it. Path Reporters send PATH_REPORT to the CREM port of the CSF address configured for the flow's source prefix, or, by default, to the flow's source address. A CSF in a gateway on the path toward the source intercepts reports addressed to the sources it serves. A PATH_REPORT MUST fit in the path MTU; a reporter truncates the dropped-PSN lists and sets the Truncated flag (0x80) if needed. When reverse-path capacity is scarce, a Path Reporter that forwards PATH_REPORT messages from downstream reporters for the same CSF MAY merge their Hop Entries with its own into one PATH_REPORT, up to 16 entries, within an aggregation interval (RECOMMENDED: 50 microseconds). Reporters MUST rate-limit PATH_REPORT per flow and per port. Alternate Marking, where it is deployed, is a measurement function of the network operator and is applied independently of CREM, for example in IPv6 options added and removed at the edges of the measured domain [RFC9343]. CREM itself does not mark or modify protected packets. A CSF MUST accept PATH_REPORT only from the set of reporter addresses configured for the domain. Path reports influence only redundancy, the timing of retransmission, and loss classification; they never cause the CSF to deem data delivered. 9. Message Formats 9.1. Common Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: CREM Common Header Li, et al. Expires 6 May 2027 [Page 14] Internet-Draft CREM for RDMA November 2026 Version is 1. Length is the length of the message in octets, including this header. Flow ID is assigned by the CRF in HELLO_ACK and is zero in HELLO and in PATH_REPORT. Integers are in network byte order. Types: 1 REPAIR, 2 HELLO, 3 HELLO_ACK, 4 PARAM_UPDATE, 5 PARAM_ACK, 6 REPAIR_REQUEST, 7 LOSS_REPORT, 8 PATH_REPORT, 9 CLOSE. Messages with an unknown Version or Type MUST be discarded. 9.2. REPAIR 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Config ID | Scheme | k | Repair Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Start PSN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Repair Session ID | Symbol Length T | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Present Bitmap (ceil(k/32) 32-bit words) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lost Source Bitmap (ceil(k/32) words, RETX flag only) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Repair Symbol (T octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: REPAIR Message (Type 1) after the Common Header Flags: 0x80 RETX (coded retransmission; the Lost Source Bitmap is present), 0x40 LAST (last repair symbol the CSF intends to send for this block in this round), 0x20 INFO (block information only; Symbol Length is zero and no symbol follows). Repair Session ID is zero for ordinary repair symbols. In both bitmaps, bit j (counting from the most significant bit of the first word) refers to position j; in the Present Bitmap it is set if position j carries a source packet, and in the Lost Source Bitmap if source j is in L. k is 1 to 255. 9.3. HELLO and HELLO_ACK Li, et al. Expires 6 May 2027 [Page 15] Internet-Draft CREM for RDMA November 2026 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Kind | AF | Supported Schemes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max k | Max m | Max T | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDMA MTU | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Nonce (64 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address (4 or 16 octets, per AF) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address (4 or 16 octets, per AF) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: HELLO (Type 2) after the Common Header Flow Kind is 1 for RoCEv2. AF is 4 or 6. Supported Schemes is a bitmap with bit s (from the least significant bit) set if scheme s is supported. RDMA MTU is the path MTU of the RDMA connection in octets of payload per packet. For RoCEv2 the Flow Label holds the destination queue pair number in its low 24 bits. HELLO_ACK (Type 3) carries the same first twelve octets with the CRF's Supported Schemes, Max k, Max m, and Max T (RDMA MTU echoed), followed by the echoed Sender Nonce, Max Open Blocks (16 bits), and 16 reserved bits; the Flow ID in its header is the assigned identifier. HELLO_ACK is therefore never larger than HELLO. 9.4. PARAM_UPDATE and PARAM_ACK PARAM_UPDATE (Type 4) carries Config ID (8 bits), Scheme (8 bits), k (8 bits), m (8 bits), T (16 bits), Reserved (16 bits), Effective PSN (24 bits), and Reserved (8 bits). PARAM_ACK (Type 5) carries Config ID (8 bits), Status (8 bits; 0 accepted, 1 unsupported scheme, 2 limits exceeded, 3 resources exhausted), and Reserved (16 bits). A CSF that receives a non-zero Status keeps its current configuration. Li, et al. Expires 6 May 2027 [Page 16] Internet-Draft CREM for RDMA November 2026 9.5. REPAIR_REQUEST REPAIR_REQUEST (Type 6) has two forms. The block form carries Config ID (8 bits), Scheme (8 bits), k (8 bits), Repairs Held r (8 bits), Block Start PSN (24 bits), Suggested M (8 bits), Request ID (16 bits), Reserved (16 bits), and the Lost Source Bitmap (ceil(k/32) words). The PSN-range form, indicated by flag 0x10 RANGES, carries Request ID (16 bits), Range Count (16 bits), and Range Count entries of Start PSN (24 bits) and Count (8 bits). Flag 0x20 FALLBACK requests Source Copy symbols for the lost sources. 9.6. LOSS_REPORT LOSS_REPORT (Type 7) carries Interval (32 bits, microseconds), Expected (32 bits), Received (32 bits), Restored (32 bits), Incomplete Blocks (32 bits), CE Marked (32 bits), Repairs Received (32 bits), and Repairs CE Marked (32 bits), all counts for the interval. 9.7. PATH_REPORT Li, et al. Expires 6 May 2027 [Page 17] Internet-Draft CREM for RDMA November 2026 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | Entry Count | AF | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow source and destination address (4 or 16 octets each) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Entry 1 (see below) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hop Entry: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Marking Period Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lost Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue Delay Change (signed, us) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause | PSN Count | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Dropped PSN (24 bits), repeated PSN Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: PATH_REPORT (Type 8) after the Common Header Method: 1 Alternate Marking [RFC9341], 2 Clustered Alternate Marking [RFC9342], 3 node-local drop accounting. The flow is identified by addresses and Flow Label as in HELLO, because a Path Reporter does not know the Flow ID. Entry Count is at most 16. 9.8. CLOSE CLOSE (Type 9) carries a Reason (16 bits) and Reserved (16 bits). Either side sends it to release the flow's state. Reasons: 0 normal termination, 1 flow ended, 2 parameter synchronization failed, 3 resources exhausted, 4 circuit breaker. Li, et al. Expires 6 May 2027 [Page 18] Internet-Draft CREM for RDMA November 2026 10. Congestion Control Considerations Repair traffic adds load to the network. The congestion control of an RDMA flow normally runs in the RDMA interface, which a CSF in a host shim or gateway cannot influence directly, and REPAIR messages use a different UDP port and can therefore take a different path under equal-cost multipath routing. CREM therefore limits repair traffic itself: * The rate of ordinary repair symbols MUST NOT exceed m/k times the measured rate of the protected flow, and the volume of coded retransmissions MUST NOT exceed the volume of source packets reported lost. * REPAIR messages carry the DSCP of the protected flow and are ECN capable. When LOSS_REPORT shows CE marks or loss on REPAIR messages, the CSF MUST reduce m (to zero if the condition persists for more than one second) in addition to applying the classification of Section 5.3. * A CSF integrated with the RDMA interface SHOULD also count REPAIR octets against the flow's congestion control, so that redundancy trades the flow's own goodput for lower latency. Because redundancy is not raised for congestion-related loss, CREM does not amplify congestion. These rules follow [RFC8085] and [RFC9743]. As a circuit breaker in the sense of [RFC8084], a CSF that observes a path loss rate (from LOSS_REPORT, before restoration) above ten percent or a CE fraction above fifty percent over one second MUST set m to zero and stop coded retransmission for the flow, leaving recovery to the RDMA transport. The flow stays open, so LOSS_REPORT messages continue, and the CSF resumes redundancy only after the condition has been absent for at least ten seconds. If the condition persists for more than one minute, the CSF sends CLOSE with reason 4. 11. Operational Considerations * MTU: a REPAIR message is larger than a source packet by its header (20 octets plus both bitmaps) and the CREM UDP/IP headers. The symbol length T plus these headers MUST fit the path MTU. * Memory: the CSF keeps the source symbols of unacknowledged blocks; the CRF keeps up to Max Open Blocks blocks. Both are bounded by the bandwidth-delay product of the path. Li, et al. Expires 6 May 2027 [Page 19] Internet-Draft CREM for RDMA November 2026 * Gateways: a pair of CREM gateways at the ends of a long-distance segment can protect all RDMA flows crossing it, so that end hosts need no changes. * Monitoring: implementations SHOULD expose the configured (k, m), restored packets, coded retransmissions and their sizes, fallbacks, and the loss classification. 12. Security Considerations Data integrity is the main concern. A forged REPAIR message would make the CRF reconstruct wrong packets, which the RDMA receiver would place into application memory. The invariant CRC of RoCEv2 detects accidental corruption of restored packets but not a deliberate forgery. Deployments MUST therefore either protect CREM messages, and the protected flow, with IPsec ESP [RFC4303], or confine CREM to a limited domain whose boundary drops datagrams addressed to the CREM port from outside. The random Sender Nonce and Flow ID make blind injection unlikely but do not authenticate messages. Forged REPAIR_REQUEST or PATH_REPORT messages could cause the CSF to send additional repair traffic. The amount is bounded: at most X symbols per block per round trip, within the rate limits of Section 10; REPAIR messages are sent only to the address bound at HELLO, never to the source of a request; and PATH_REPORT is accepted only from configured reporters. HELLO is no smaller than HELLO_ACK, so CREM cannot be used for reflection amplification. Path reports reveal per-hop loss and delay. They are sent only to sources of protected flows inside the domain. 13. IANA Considerations This document requests no port number; the CREM port is configured per limited domain (Section 3). 13.1. CREM Registries IANA is requested to create a registry group named "CREM Parameters" with the following registries. Unless stated otherwise, values are assigned by Specification Required [RFC8126] and the upper quarter of each value space is reserved for Private Use. * "CREM Message Types" (4 bits): 0 Reserved, 1 REPAIR, 2 HELLO, 3 HELLO_ACK, 4 PARAM_UPDATE, 5 PARAM_ACK, 6 REPAIR_REQUEST, 7 LOSS_REPORT, 8 PATH_REPORT, 9 CLOSE. Assignments require Standards Action. Li, et al. Expires 6 May 2027 [Page 20] Internet-Draft CREM for RDMA November 2026 * "CREM FEC Schemes" (8 bits): 0 Source Copy, 1 Cauchy Reed-Solomon GF(2^8), 2 XOR Parity. * "CREM Flow Kinds" (8 bits): 0 Reserved, 1 RoCEv2. * "CREM Measurement Methods" (8 bits): 0 Reserved, 1 Alternate Marking, 2 Clustered Alternate Marking, 3 Node-local drop accounting. * "CREM Loss Causes" (8 bits): 0 Unknown, 1 Queue overflow, 2 Transmission error. * "CREM PARAM_ACK Status Codes" (8 bits): 0 Accepted, 1 Unsupported scheme, 2 Limits exceeded, 3 Resources exhausted. * "CREM CLOSE Reasons" (16 bits): 0 Normal termination, 1 Flow ended, 2 Parameter synchronization failed, 3 Resources exhausted, 4 Circuit breaker. * "CREM Message Flags": one entry per bit of the 8-bit Flags field and message type; initial contents REPAIR 0x80 RETX, 0x40 LAST, and 0x20 INFO, REPAIR_REQUEST 0x20 FALLBACK and 0x10 RANGES, PATH_REPORT 0x80 Truncated. The designated experts should verify that new FEC schemes specify the coding of absent positions and whether coded retransmission is supported, and that new flow kinds specify how sources and PSN positions are identified. 14. References 14.1. Normative References [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC768, August 1980, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . Li, et al. Expires 6 May 2027 [Page 21] Internet-Draft CREM for RDMA November 2026 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, . [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T., and T. Zhou, "Alternate-Marking Method", RFC 9341, DOI 10.17487/RFC9341, December 2022, . [RFC9342] Fioccola, G., Ed., Cociglio, M., Sapio, A., Sisto, R., and T. Zhou, "Clustered Alternate-Marking Method", RFC 9342, DOI 10.17487/RFC9342, December 2022, . [RFC9343] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. Pang, "IPv6 Application of the Alternate-Marking Method", RFC 9343, DOI 10.17487/RFC9343, December 2022, . Li, et al. Expires 6 May 2027 [Page 22] Internet-Draft CREM for RDMA November 2026 14.2. Informative References [I-D.chen-rdma-windowless-ack] Chen, D. and H. Yang, "Windowless Cumulative ACK Extension for RDMA Retransmission", Work in Progress, Internet- Draft, draft-chen-rdma-windowless-ack-00, 6 July 2026, . [I-D.dmoskvitin-quic-adaptive-fec] Moskvitin, D., Onegin, E., Huang, R., Luo, H., and Q. Chen, "Adaptive Forward Erasure Correction for Delay- Sensitive QUIC Connections", Work in Progress, Internet- Draft, draft-dmoskvitin-quic-adaptive-fec-00, 6 May 2024, . [I-D.hzh-fantel-wan-tunnel] Hu, Z., Zhu, Y., Hu, J., and T. Pi, "Fast Notification for tunnel-based lossless RDMA transmission in WAN", Work in Progress, Internet-Draft, draft-hzh-fantel-wan-tunnel-03, 27 June 2026, . [I-D.ietf-dtn-btpu-fec] Taylor, R., "Forward Error Correction for the Bundle Transfer Protocol", Work in Progress, Internet-Draft, draft-ietf-dtn-btpu-fec-03, 15 October 2026, . [I-D.li-tsvwg-inference-transport] Li, Z., Du, Z., Wang, J., Cheng, W., Zhang, G., Sun, X., and C. Zhao, "Transport Considerations for Large-Scale Distributed Inference Networks", Work in Progress, Internet-Draft, draft-li-tsvwg-inference-transport-00, 4 July 2026, . [I-D.liu-opsawg-alt-mark-per-packet] Liu, K. and R. Wang, "Alternate marking usage for loss location in per-packet load balancing networks", Work in Progress, Internet-Draft, draft-liu-opsawg-alt-mark-per- packet-00, 2 March 2026, . Li, et al. Expires 6 May 2027 [Page 23] Internet-Draft CREM for RDMA November 2026 [I-D.michel-quic-fec] Michel, F. and O. Bonaventure, "Forward Erasure Correction for QUIC loss recovery", Work in Progress, Internet-Draft, draft-michel-quic-fec-01, 23 October 2023, . [I-D.sang-fann-fast-network-event-notification] Sang, L., Geng, X., and H. Deng, "Problem Statement and Requirements for Fast Network Event Notification in Distributed AI Training and Inference", Work in Progress, Internet-Draft, draft-sang-fann-fast-network-event- notification-01, 3 July 2026, . [IBTA-ROCEV2] InfiniBand Trade Association, "Supplement to InfiniBand Architecture Specification Volume 1 Release 1.2.1, Annex A17: RoCEv2", September 2014, . [RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. Garcia, "A Remote Direct Memory Access Protocol Specification", RFC 5040, DOI 10.17487/RFC5040, October 2007, . [RFC5044] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. Carrier, "Marker PDU Aligned Framing for TCP Specification", RFC 5044, DOI 10.17487/RFC5044, October 2007, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [RFC9743] Duke, M., Ed. and G. Fairhurst, Ed., "Specifying New Congestion Control Algorithms", BCP 133, RFC 9743, DOI 10.17487/RFC9743, March 2025, . Appendix A. Coding Example This example uses scheme 1 with k = 4 and T = 16. The UDP payloads of the four source packets are the ASCII strings "RDMA-PKT-0" to "RDMA-PKT-3" (10 octets each), so each source symbol is the length 0x000a, the payload, and four octets of padding: Li, et al. Expires 6 May 2027 [Page 24] Internet-Draft CREM for RDMA November 2026 S0 = 000a52444d412d504b542d3000000000 S1 = 000a52444d412d504b542d3100000000 S2 = 000a52444d412d504b542d3200000000 S3 = 000a52444d412d504b542d3300000000 Coefficients C(i, j) for i = 0..2 and j = 0..3 (x_i = 255 - i, y_j = j): j=0 j=1 j=2 j=3 i=0: fd 7e ff 7f i=1: 7e fd 7f ff i=2: ff 7f fd 7e With m = 2 the CSF sends R0 and R1 over the whole block: R0 = 001ef6ccd7c377f0ddfc774c00000000 R1 = 001ef6ccd7c377f0ddfc774f00000000 Sources 0, 1, and 2 are lost (X = 3); the CRF holds S3, R0, and R1 (r = 2) and requests M = X - r = 1 symbol for L = {0, 1, 2}. The CSF sends the coded retransmission with Repair Index 2 over L only: R2[L] = 00354fdf6d4b40b57e5c400000000000 The CRF subtracts C(0,3)*S3 from R0 and C(1,3)*S3 from R1 and solves the 3 x 3 Cauchy system with rows i = 0, 1, 2 and columns j = 0, 1, 2, recovering S0, S1, and S2. Three lost packets were recovered with one retransmitted symbol. The REPAIR message for R2[L] (Flow ID 0x0000BEEF, Config ID 1, Block Start PSN 0x001000, Repair Session ID 7, all four positions present, so Present Bitmap 0xF0000000 and Lost Source Bitmap 0xE0000000) begins as follows and is followed by the 16 octets of R2[L], for a total Length of 44: 11 80 00 2c 00 00 be ef 01 01 04 02 00 10 00 00 00 07 00 10 f0 00 00 00 e0 00 00 00 Acknowledgments The authors thank the participants in discussions on RDMA over long- distance networks for their comments. Authors' Addresses Zhiqiang Li China Mobile Beijing 100053 China Li, et al. Expires 6 May 2027 [Page 25] Internet-Draft CREM for RDMA November 2026 Email: lizhiqiangyjy@chinamobile.com Zongpeng Du China Mobile Beijing 100053 China Email: duzongpeng@chinamobile.com Junjie Wang Centec Shanghai 201203 China Email: wangjj@centec.com Wei Cheng Centec Shanghai 201203 China Email: chengw@centec.com Ying Zhao Centec Shanghai 200000 China Email: zhaoying@centec.com Chunhao Zhao SAIA Shanghai 200125 China Email: chunhao.zhao@sh-aia.com Xun Sun Inesa Shanghai 200030 China Li, et al. Expires 6 May 2027 [Page 26] Internet-Draft CREM for RDMA November 2026 Email: sunxun@inesa.com Li, et al. Expires 6 May 2027 [Page 27]