## 2 Related Works and Motivations
### Motivations for the Status-Byte-Assisted RDMA Transmission Mechanism  
Currently, there are two primary transmission mechanisms: traditional RDMA data transmission and sliding window-based data transmission [11]. Traditional RDMA data transmission requires at least three network interactions: memory address notification, remote data reading/writing, and completion notification. This method incurs significant overhead in communication control and is more suitable for scenarios where transmissions are infrequent and latency is less critical. As illustrated in Figure 1a, the sliding window technique proposed by [PERSON] et al. requires only two RDMA interactions per transmission. This technique consists of two phases: initialization and data transmission. In the initialization phase, the sender invokes the memory pool initialization interface (RmInit). RmInit is an interface that sets up the sliding window using the received memory pool information (address, length, and KEY). This function of RmInit is to initialize the memory pool for use in the RDMA communication and create a circular queue with \(n\) members, as shown in Figure 1b. The sender then uses the remote memory write interface (RmWrite) to perform data transmission. RmWrite is an interface that writes data to a specified remote memory location. The RDMA Write With Immediate (Write_with_imm) operation is utilized, which includes immediate data to notify the receiver about the data's starting position and length. After the data has been processed, the receiver sends an ACK notification to confirm receipt. Finally, the sender calls the memory release interface (RmFree). RmFree is an interface that updates the sliding window status by releasing the memory block and making it available for reuse. However, this sliding window transmission mechanism has several limitations. As illustrated in Figure 1c, the sliding window tracks the usage status of all memory blocks with two pointers, which necessitates that memory block sending and releasing memory blocks follow a strict sequence, resulting in a lack of flexibility. During task transmission, as shown in Figure 1d, if an ACK confirmation for a memory block is not received promptly or the memory block at the receiver needs to remain in waiting status, the head pointer cannot advance and the window position occupied by this data block cannot be released for new data. When the tail pointer cycles back to this position, the system might misinterpret the situation as no available memory blocks, despite actual availability, leading to transmission delays or even crashes due to the logical constraints of the sliding window. Additionally, this transmission mechanism requires the receiver to actively return ACK notifications and the sender to periodically poll for ACK notifications. This method not only consumes the receiver's CPU resources but also results in poor real-time performance. When processing the transmission of multiple data streams of various devices, the receiver may require multiple processing threads, which may result in varying sequences of ACK returns. Given that the release of sliding window memory blocks must follow  
Figure 1: (a) Data transmission process based on sliding window mechanism; (b–d) Memory analysis of sliding window transmission mechanism facing special status. a strict order, this can easily lead to confusion in the release of memory blocks, making it difficult to handle the inputs from multiple devices effectively. If concurrency control mechanisms are employed to synchronize access to resources, it will severely impact RDMA performance, rendering it no better than single-threaded performance [30]. Thus, when transmitting data streams from multiple devices, the sliding window transmission mechanism typically requires establishing multiple RDMA connections, which consumes significant RDMA NIC resources [31; 32], potentially leading to performance bottlenecks.