# Inter-Data Center RDMA: Challenges, Status, and Future Directions
## 4 Existing Representative Works
### Comparison
Some require the addition of dedicated devices to existing links [19]; others necessitate modifications to the hardware logic of egress switches (i.e., DCI switches) [23] or even require to design specific hardware functions for DCI switches and NICs located in end hosts [49; 50; 51]. In contrast, non-RDMA-specific solutions employ almost entirely software-based implementations. They are generally developed either based on the universal congestion control interface defined in the Linux kernel protocol stack [52; 54; 55; 56] or by developing a dedicated module and installing it into the protocol stack [53]. As can be seen in the Table 4, non-RDMA-specific solutions are much simpler to deploy than RDMA-specific solutions. However, RDMA-specific approaches, through redesigning or modifying existing hardware, introduce specialized hardware that better aligns with their methods, enabling them to achieve higher performance. As summarized in Table 5, RDMA-specific solutions primarily rely on reactive and hybrid congestion control methods, each tailored to improve response speed. Some solutions introduce dedicated devices to enhance feedback efficiency, while others use measurement techniques to monitor real-time link conditions, improving feedback accuracy. A few approaches break the congestion control loop by using near-end feedback to accelerate rate adjustments. These solutions are typically designed for lossless networks, often as enhancements to PFC-based schemes. Additionally, they frequently involve redesigning or modifying hardware processing logic to align with their proposed algorithms, resulting in superior performance. In contrast, non-RDMA-specific solutions employ a wider range of \begin{table}
\begin{tabular}{c c c c c} \hline \hline \multirow{2}{*}{**Scheme**} & **Implementation** & **Implementation** & **Deployment** & **Performance** \\  & **Method** & **Location** & **Complexity** & **Potential** \\ \hline SWING [19] & Addition of dedicated device & Existing links & Medium & Medium \\ \hline BiFrost [23] & Modification to the hardware logic of DCI switches & DCI switches & Medium & Medium \\ \hline LSCC [49] & Design of specific hardware functions for DCI switch and NICs & DCI switch and NICs & High & High \\ \hline BiCC [50] & Design of specific hardware functions for DCI switch and NICs & DCI switch and NICs & High & High \\ \hline LoWAR [51] & Design of specific hardware functions for DCI switch and NICs & DCI switch and NICs & High & High \\ \hline GEMINI [52] & Software-based implementation & End-host protocol stack & Low & Low \\ \hline FlashPass [53] & Software-based implementation & End-host protocol stack & Low & Low \\ \hline GTCP [54] & Software-based implementation & End-host protocol stack & Low & Low \\ \hline IDCC [55] & Software-based implementation & End-host protocol stack & Low & Low \\ \hline Annulus [56] & Software-based implementation & End-host protocol stack & Low & Low \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Comparison of existing works in terms of implementation. congestion control methods, including reactive, proactive, and hybrid approaches. They do not require high network reliability (i.e., lossless networks) and are generally compatible with lossy networks. Furthermore, their implementations are primarily software-based, making them simpler and more flexible.