<?xml version="1.0" encoding="US-ASCII"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com 
     This can be converted using the Web service at http://xml.resource.org/ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- You want a table of contents -->
<!-- Use symbolic labels for references -->
<!-- This sorts the references -->
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<?rfc sortrefs="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<rfc category="info" docName="draft-chen-rdma-windowless-ack-00"
     ipr="trust200902">
  <front>
    <title abbrev="Network Working Group">Windowless Cumulative ACK Extension
    for RDMA Retransmission</title>

    <author fullname="Danyang Chen" initials="D." surname="Chen">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>chendanyang@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Hongwei Yang" initials="H." surname="Yang">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>yanghongwei@chinamobile.com</email>
      </address>
    </author>

    <!---->

    <date day="6" month="July" year="2026"/>

    <area>Networking</area>

    <workgroup>Internet Research Task Force</workgroup>

    <keyword>RDMA, ACK mechanism</keyword>

    <abstract>
      <t>Traditional RDMA Reliable Connection (RC) uses selective
      retransmission, while TCP SACK depends on sliding window and RTO timer
      tuning. Both mechanisms waste network bandwidth when window or RTO
      parameters mismatch real network conditions. This document defines a
      windowless cumulative selective acknowledgement extension (T/C AETH)
      embedded within the RDMA ETH header, paired with dual-trigger ACK
      reporting logic driven by cumulative receive time threshold and
      cumulative received packet count threshold.</t>

      <t>The receiver generates extended SACK reports without sliding window
      constraints. The sender accurately identifies lost PSN segments through
      multi-segment confirmation fields carried in T/C AETH, then only
      retransmits missing packets. This design removes window dependency,
      eliminates redundant retransmissions, and improves bandwidth utilization
      and end-to-end throughput for high-speed RDMA workloads in data centers
      and wide-area networks.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>Existing reliable transport retransmission schemes have two major
      categories with inherent defects:<list>
          <t>TCP SACK and Go-Back-N: Performance heavily relies on sliding
          window size and RTO timeout configuration. Small window generates
          excessive reverse-path ACK overhead; oversized window triggers
          massive redundant retransmissions once packet loss occurs.</t>

          <t>Standard RDMA AETH SACK: Only supports a single continuous
          receive segment, cannot compact multiple discontinuous received PSN
          blocks into one ACK frame.</t>
        </list></t>

      <t>For high-throughput RDMA workloads including distributed AI training,
      distributed storage, and cross-DC data replication, minor mismatch
      between tuning parameters and actual network conditions significantly
      degrades link utilization. This draft introduces two core
      innovations:<list>
          <t>Dual-trigger ACK reporting: The receiver sends extended SACK once
          either cumulative receive time or cumulative received packet count
          reaches preconfigured threshold; per-packet ACK is eliminated.</t>

          <t>Extended T/C AETH fragment inserted into RDMA ETH header: Carries
          multiple discontinuous receive segments, enabling precise selective
          retransmission without receiver-side sliding window maintenance.</t>
        </list></t>

      <t>The proposed mechanism fully removes sliding window constraints. The
      sender transmits data at a fixed preset line rate continuously, while
      the receiver batches loss feedback via extended ACK to minimize
      control-plane overhead on reverse path.</t>

      <t>This specification extends the RDMA ETH header defined in [RFC5040]
      by introducing a new Target Fragment (T/C AETH). It defines end-to-end
      operation rules for RC QP pairs, applicable to RoCEv1, RoCEv2 and
      InfiniBand RC transport. This draft does not modify RDMA data payload
      format or existing congestion control algorithms.</t>

      <t>Currently, the application of RDMA for data transmission in wide area
      networks encounters the following issues:<list>
          <t>Go-Back-N Limitation: If a single PSN is lost, the sender
          retransmits all outstanding packets after the last acknowledged PSN,
          resulting in severe bandwidth waste under non-zero packet loss
          rate.</t>

          <t>Sliding Window Overhead: Credit-based window requires frequent
          ACK feedback to advance transmission window. Small window causes ACK
          flooding on reverse path; large window leads to bulk redundant
          retransmission upon loss.</t>

          <t>RTO Sensitivity: Underestimated RTO induces spurious
          retransmissions; overestimated RTO stalls throughput for
          long-latency cross-DC links.</t>

          <t>Single Segment AETH Restriction: Legacy RDMA AETH only reports
          one continuous receive range, cannot aggregate multiple
          discontinuous received blocks into a single ACK frame.</t>
        </list></t>

      <t>This draft resolves all above limitations via windowless transmission
      combined with multi-segment batch SACK reporting.</t>
    </section>

    <section title="Mechanism Overview">
      <t>The complete end-to-end workflow contains two symmetric operation
      planes:<list>
          <t>Receiver Plane (Section 5): Accumulate received PSNs, monitor
          dual time/count thresholds, construct T/C AETH extended ACK and
          transmit to sender when any threshold is hit.</t>

          <t>Sender Plane (Section 6): Transmit packets at fixed preset rate
          without sliding window limitation; parse multi-segment blocks in T/C
          AETH to extract missing PSN ranges, perform selective retransmission
          only for identified lost segments.</t>
        </list></t>

      <t>Core technical advantages:<list>
          <t>Windowless sender transmission: No per-flow credit window
          tracking required on sender side.</t>

          <t>Batch ACK reporting: Dual-threshold batching drastically reduces
          reverse-path ACK traffic volume.</t>

          <t>Multi-segment compact SACK: Single ACK frame carries multiple
          discontinuous received PSN ranges to enable precise loss
          recovery.</t>
        </list></t>

      <t>High-Level End-to-End Flow:<list>
          <t>Sender continuously transmits RDMA data packets at negotiated
          fixed preset rate.</t>

          <t>Receiver accumulates received data packets, tracks cumulative
          receive time and cumulative packet count.</t>

          <t>If cumulative time &gt;= T_thresh OR cumulative count &gt;=
          C_thresh: a. Receiver constructs RDMA ACK frame with embedded T/C
          AETH target fragment. b. Transmit extended ACK (First Message) back
          to sender QP.</t>

          <t>Sender parses T/C AETH segments, calculates PSN gaps between all
          confirmed receive blocks.</t>

          <t>Sender selectively retransmits only PSN ranges identified as
          lost.</t>

          <t>Fallback timeout retransmission activates if sender receives no
          extended ACK after fixed timeout window expires.</t>
        </list></t>
    </section>

    <section title="Receiver Operation">
      <t>For threshold configuration, during RC QP setup handshake:<list>
          <t>Sender advertises its preset packet send rate to receiver via CM
          REQ/REP.</t>

          <t>Receiver computes and configures T_thresh (cumulative time
          threshold) and C_thresh (cumulative count threshold) proportional to
          sender transmission rate.</t>
        </list></t>

      <t>Receiver maintains per-QP batch state variables:<list>
          <t>BatchStartTime: Timestamp of the first packet received in current
          batch cycle. - BatchPacketCount: Total valid unique PSNs received in
          current batch.</t>

          <t>SegmentList: Ordered list of continuous received PSN blocks,
          sorted by ascending PSN value.</t>
        </list></t>

      <t>For each incoming valid data packet: <list>
          <t>Record PSN if packet is valid and not duplicate.</t>

          <t>Merge new PSN into existing continuous segment in SegmentList, or
          create a new standalone segment block.</t>

          <t>Increment BatchPacketCount counter by one.</t>

          <t>Calculate current cumulative receive time = CurrentTime -
          BatchStartTime.</t>
        </list></t>

      <t>After batch receive state tracking, it transmits T/C AETH extended
      ACK when either condition evaluates to true:<list>
          <t>Condition A: Cumulative receive time &gt;= T_thresh</t>

          <t>Condition B: Cumulative receive count &gt;= C_thresh</t>
        </list></t>

      <t>After sending extended ACK frame: <list>
          <t>Reset BatchStartTime to current system timestamp.</t>

          <t>Clear BatchPacketCount to zero.</t>

          <t>Flush SegmentList to empty for new batch collection cycle.</t>
        </list></t>

      <t>To complete the extended ACK transmission, the sender needs to
      construct an extended ACK frame.<list>
          <t>Base frame: Standard RDMA ACK ETH header sequence defined in
          RFC5040.</t>

          <t>Insert new T/C AETH Target Fragment between standard AETH and
          Atomic AETH fields inside ETH header.</t>

          <t>Populate all T/C AETH fields with data extracted from
          SegmentList, detailed format specified in Section 7.</t>

          <t>Encapsulate complete ACK frame and transmit to corresponding
          sender QP.</t>
        </list></t>
    </section>

    <section title="Sender Operation">
      <t>In this draft, we design a windowless continuous transmission. After
      QP establishment handshake completes: <list>
          <t>Sender transmits data packets at pre-negotiated fixed preset rate
          continuously.</t>

          <t>No sliding window credit check is executed before sending new
          outbound packets.</t>

          <t>Cache all transmitted PSNs within send buffer for potential
          selective retransmission processing.</t>
        </list></t>

      <t>Upon receiving T/C AETH extended ACK frame: <list>
          <t>Parse SegmentNum field to read total number of valid receive
          confirmation segments stored inside Target Fragment.</t>

          <t>Extract Last Finished PSN, representing end PSN of first
          continuous fully received block.</t>

          <t>Extract each subsequent SegX Left / SegX Right pair representing
          discontinuous received PSN blocks.</t>

          <t>Compute all PSN gaps between adjacent confirmed segments; these
          gaps are defined as lost packet ranges.</t>

          <t>Trigger selective retransmission for all PSNs inside identified
          gap ranges only.</t>
        </list></t>

      <t>The designed multi-segment loss calculation logic is as follows:<list>
          <t>Case 1: SegmentNum = 1 (single continuous received block) All
          PSNs smaller than Last Finished PSN are fully received without loss.
          Lost packets = all PSNs greater than Last Finished PSN up to latest
          transmitted PSN.</t>

          <t>Case 2: SegmentNum &gt; 1 (multiple discontinuous receive
          segments) Lost range 1: (Last Finished PSN, Seg1 Left PSN) Lost
          range N: (SegN Right PSN, SegN+1 Left PSN) All PSNs inside above
          intervals shall be retransmitted by sender.</t>
        </list></t>
    </section>

    <section title=" T/C AETH Target Fragment Header Format">
      <t>The T/C AETH fragment occupies fixed 30 Bytes inside RDMA ETH header,
      inserted between standard AETH and Atomic AETH subheaders. All fields
      use big-endian byte order, aligned to 24-bit unless otherwise
      specified.</t>

      <section title="Binary Layout (30 Bytes Total)">
        <t><figure>
            <artwork>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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SegmentNum(24b)| Last Finished PSN (24bit)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seg1 Left(24b)| Seg1 Right(24b)                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seg2 Left(24b)| Seg2 Right(24b)                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seg3 Left(24b)| Seg3 Right(24b)        Reserved (24 bits)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
          </figure></t>

        <t>SegmentNum (24 bits): Count of valid receive confirmation segments.
        Valid range: 1 &le; SegmentNum &le; 4. Values exceeding 4 are treated
        as reserved.</t>

        <t>Last Finished PSN (24 bits): Maximum PSN of the first continuous
        receive block (continuous segment without prior packet loss).</t>

        <t>SegX Left (24 bits): Minimum PSN of discontinuous received segment
        X.</t>

        <t>SegX Right (24 bits): Maximum PSN of discontinuous received segment
        X.</t>

        <t>Reserved (24 bits): Future extension field, set to all zero bits on
        transmission, ignored entirely on receiver processing.</t>
      </section>

      <section title=" Segment Mapping Visualization">
        <t>T/C AETH fragment encodes receive state in following logical
        sequence: [Continuous Segment: 0 ~ Last Finished PSN] | Lost Gap 1 |
        [Seg1 Left ~ Seg1 Right] | Lost Gap2 | [Seg2 Left ~ Seg2 Right]
        ...</t>
      </section>
    </section>

    <section title="Retransmission Decision">
      <t>Sender strictly retransmits only PSNs within gap ranges calculated
      from T/C AETH segment fields. No extra packets outside lost intervals
      are retransmitted, eliminating redundant retransmission overhead
      existing in Go-Back-N and oversized sliding window implementations.</t>

      <t>For example, sender transmits PSN range 100 ~ 599 at fixed preset
      rate. Receiver receives continuous block 100~199, loses 200~299,
      receives 300~399, loses 400~499, receives 500~599.</t>

      <t>Corresponding T/C AETH field values:<list>
          <t>SegmentNum = 3</t>

          <t>Seg1 Left=300, Seg1 Right=399</t>

          <t>Seg2 Left=500, Seg2 Right=599</t>
        </list></t>

      <t>Sender identifies lost ranges: 200~299, 400~499; retransmits only
      these two PSN intervals.</t>

      <t>To handle potential loss of extended ACK frames on reverse data path:
      <list>
          <t>Sender maintains per-QP ACK timeout timer configured during QP
          setup.</t>

          <t>If sender transmits PSN range [X, Y] and receives no T/C AETH
          frame after timeout expires: a. Retransmit the latest transmitted
          sequential PSN block (highest PSNs sent). b. Restart ACK timeout
          timer immediately after retransmission.</t>

          <t>Fallback timeout mechanism serves only as safety backup; primary
          loss recovery relies on extended T/C AETH SACK reports.</t>
        </list></t>
    </section>

    <section anchor="Security" title="Security Considerations"/>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document has no requests to IANA.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
    </references>
  </back>
</rfc>
