## 2 Methods
### Reliable Transmission Design Mechanism
#### 2.1.2 NACK Dynamic Adjustment Transmission Mechanism
\begin{table}
\begin{tabular}{c c} \hline \hline
**Solution** & **Throughput (Gbps)** \\ \hline TCP Reno & 0.038 \\ TCP Cubic & 0.030 \\ TCP BBR & 0.718 \\ RDMA & 0.03 \\ Our Work & 7.68 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Comparison of the efficiency of different technologies. Figure 13: Real-world long-distance transport network topology. Overall, by employing link retransmission, we prevent the significant reduction in throughput often associated with congestion control on the device side. Compared to other link-layer retransmission mechanisms, our approach enhances tolerance to out-of-order packets, thereby avoiding the bandwidth consumption incurred by false retransmissions. ### Limitations and Future Work

While our research has made significant strides, there are certain limitations that warrant acknowledgment and attention in future studies. One such limitation is the handling of out-of-order packets resulting from retransmissions, which currently lacks a specific mechanism for reordering at the nodes. Additionally, although the algorithm and mechanisms we implemented in software provide a high degree of flexibility, the forwarding speed and throughput are somewhat constrained because of device platform limitations. This trade-off between flexibility and speed is a common challenge in software-defined networking, and we are committed to optimizing this in our future work. To this end, we plan to focus on the cache space required on the nodes for storing packets awaiting retransmission. The efficient utilization and management of this cache space will be a key direction for our subsequent optimization efforts. Furthermore, while we have successfully integrated our code on programmable switches to facilitate forwarding, our mechanism is also designed to run on other types of nodes because the entire program is independent of the switch, and the input and output consist only of packets. During the testing phase, we discovered that only minor configuration and code changes are necessary to enable direct packet reception and transmission from the network port on these devices. However, this adaptation requires consideration of the storage capacity needed on these alternative devices. When applying our mechanism to other types of nodes, it is also necessary to configure and modify the corresponding interfaces within the code to accommodate the specific hardware capabilities and constraints. Additionally, some header configuration is required for the packet. In summary, our future work will concentrate on refining the handling of out-of-order packets, optimizing the forwarding speed, and expanding the applicability of our mechanism to a broader range of network nodes. By addressing these limitations, we aim to enhance the overall performance and adaptability of our network retransmission scheme. ## 5 Conclusions

In this study, we implemented a novel link-local retransmission mechanism designed to enhance the reliability of data transmission in networks prone to packet loss. Our approach leverages continuous sequence numbers to facilitate efficient retransmission of lost packets, thereby maintaining the operational integrity of network links until physical repairs can be made. The implementation of this mechanism on a programmable switch platform demonstrated significant improvements in both packet loss recovery and overall network performance. Through extensive simulations and real-world testing, we showed that our algorithm effectively mitigates the impact of packet loss caused by link corruption. The results indicate that by employing a feedback mechanism that dynamically adjusts retransmission strategies based on network conditions, we can significantly reduce the effective packet loss rate. This is particularly crucial in scenarios where traditional end-to-end recovery methods may fall short, as they often misinterpret packet loss as a sign of congestion, leading to unnecessary reductions in throughput.