容损网络vs无损网络，讨论RDMA网络的两种思路
本文只代表作者个人观点
---------------------
RDMA的设计思路
（一）摘要
本文讨论，RDMA网络的2种设计思路：
容损网络：Chelsio公司主导的iWarp
无损网络：Mellanox公司主导的InfiniBand, RoCE，
Chelsio经常公开指责 RoCE的设计思路（无损）有不可克服的理论缺陷和风险，
Mellanox 从不在理论上与Chelsio辩论，而是用优秀的测试结果和客户选择回击Chelsio。
本文要讨论2个问题：
（1）为啥RoCE要求网络不许丢包，而iWarp能容忍网络丢包？
（2）RoCE“不允许网络丢包”这种要求合理吗？
（二）RDMA的两种流派的设计思路差异：
先回答第一个问题：为啥iWarp不要求网络无损，而RoCE要求网络无损？
其根本原因是：“选择重传协议” 与 “回退N帧协议” 的差异
iWarp的 “选择重传协议” 是丢哪个报文就重传哪个报文，因此对丢包不敏感。
RoCE的 “回退N帧协议” 是丢失报文序号之后的全部报文都要重发，因此对丢包非常敏感。
iWarp的性能问题，和RoCE的稳定性问题，都源于此。
| 容损网络：iWarp | 无损网络：InfiniBand, RoCE | |
| 对待丢包 |
选择性重传， 对丢包不敏感 需要缓存报文 |
回退N帧， 对丢包非常敏感 因此想尽办法让网络不丢包。 |
| 对网络的要求 |
不需要交换机配合， 不要求网络无损 |
需要交换机配合， 要求网络无损 InfiniBand是专用交换机， RoCE是普通交换机做流控配置 |
| 成本 | 略有小贵 | InfiniBand：很昂贵 --------------- RoCE：便宜 |
| 易用性 | 易用性很好 | InfiniBand：易用性较好， --------------- RoCE：配置和监控比较麻烦。 |
|
是否需要 集中管控 |
不需要leader来管理。 |
InfiniBand：SubnetManager 就是网络的leader，InfiniBand网络不能没有Leader。 --------------- RoCE：其实也需要全网紧密配合，但实际是没有leader做交换机到网卡的端到端的拉通，因此用起来很麻烦。 |
| 性能 | 时延大，性能还可以。 | 时延低，性能很好。 |
| 风险 | 存在个体性风险，主要是网卡硬件太复杂。 | 存在系统性风险，即：局部拖累整体。平时很少出问题，可一出问题就是全局性问题。 |
| 可扩展性 | 可扩展性好 | 可扩展性差，只适用于封闭的内网，无法跨地域部署。 |
（三）容损网络-iWarp
（3.1)iWarp的设计思路是：
把整个TCP/IP协议栈卸载到智能网卡中，由网卡硬件（目前是FPGA）来实现，虽然降低了CPU的负荷，但增加了iWarp网卡的硬件复杂度。
（3.2)iWarp的优点：
不要求交换机做任何配合，选择性重传对丢包相对不敏感。
（3.3)iWarp的缺点：
TCP/IP协议对于智能网卡来说过于复杂，开销大，时延大，因此iWarp的性能比RoCE差。
（3.4) 基于容损网络的其他设计思路：
SIGCOMM2018：Revisiting Network Support for RDMA
SIGCOMM2018会议上，提出了IRN（Improved RoCE NIC）算法。该设计仍然保留“选择性重传” 这一设计思路，作者认为iWarp的思路大方向正确，但是TCP协议对于智能网卡太过复杂，需要简化。截至今年（2021年），该设计仍处于实验室阶段，没有经过任何生产环境的考验。
（四）无损网络-RoCE
（4.1) RoCE的主要技术
ECN/CNP, DCQCN ：理想的情况是避免发生拥塞
PFC ：一旦发生拥塞，至少不要丢包（PFC是麻烦制造者）
Go-Back-N：一旦丢包，回退N帧，（对丢包过于敏感）
（4.2) PFC：简单的协议和不简单的后果
PFC协议说起来很简单，就是逐层向上游发送流控帧。如果下游网卡接近拥塞，就会向上游交换机发出一个PFC启动，要求交换机暂停发送。上游交换机在缓存不足时也会向自己的上游各端口发PFC。
说明下：PFC流控是基于端口的，而不是基于流的！
郭传雄曾经如此评价PFC，PFC看起来非常简单，但它所导致的后果一点也不简单。这些后果包括：
不公平降速（Unfairness）和伤及无辜（Victim flow）：
明明是网卡4即将拥塞，为啥网卡1/2/3要跟着一起流控？ 网卡1/2/3之间的通信链路，原本与网卡4毫无关系，却也被无辜的执行流控，这就是不公平降速。我举个形象的例子，假如北四环堵车，我们去南四环也一起被流控，这公平吗？
PFC风暴：
假设网卡驱动软件由于某种原因（比如挂死），没法及时处理网卡的接收队列。导致网卡一直处于拥塞状态，也就一直向上游发出PFC。导致整集群通信中断，这就是PFC风暴。
（4.3) 永远慢半拍的ECN/CNP
因为PFC存在种种问题，因此在RoCEV2中，又补充了ECN协议。
(1)发送端发送IP 报文标记ECN(ECN=10)；
(2)交换机在队列拥塞的情况下收到该报文，将ECN 字段修改为11 并转发出去；转发路径上存在拥塞。
(3)接收服务器收到ECN 为11 的报文，就知道了来自某发送端的路径上存在拥塞。
(4)接收端周期性的向转发路径上存在拥塞的Sender发送CNP（Congestion Notification Packets）报文，就是要求该Sender慢点发。ECN字段为01。
如何判定存在拥塞？要看缓冲区的水位的配置。
(5)交换机收到CNP 报文后正常转发该报文；
(6)发送服务器收到ECN 标记为01 的CNP 报文解析后对相应的数据流限速算法，目前主流的流控算法是DC-QCN。
（4.4）无法避免的微突发，瞬间多打一，
对于分布式系统，在瞬间出现多打一的情况非常常见，比如大比例EC的读操作，这个微突发拥塞往往集中在不到1个ms之内就会结束。因此ECN的拥塞处理一直慢半拍。ECN可以保证不会在一个瓶颈点出现持续的拥塞，但对瞬间的微突发作用有限。
（4.5）业界对RoCE的不满和无损网络的改进思路
显然，业界认为RoCE（尤其是对PFC）是有待改进的。否则SIGCOMM会议也不会连续5年(2015-2019)，每年都有讨论如何改进RoCE的论文了。
（a）Mellanox自己提出的备选方案：Resilient RoCE
压低ECN/CNP的水线，更低的水位就可以触发CNP降速，但不配置端口级的PFC流控。该思路其实已经是容损网络了，该配置会导致性能大幅度降低，丧失了RoCE的传统优势。
（b）阿里巴巴提出的HPCC
Sigcomm2019：High Precision Congestion Control（HPCC）
其设计思路是仍然遵循RoCE要求网络不许丢包这一原则，用可编程的白牌交换机，把整个网络从网卡到交换机，端到端的管理起来。
通过智能网卡与交换机的配合，端到端实时抓取拥塞信息，从而精确获取实时的链路负载，并且根据精确的链路负载来计算合适的发送速率。
如图所示，发送方发送的每个数据包将由接收方确认。在从发送器到接收器的数据包传播过程中，沿路径的每个交换机利用其INT功能来插入一些数据，这些数据报告了包括时间戳（ts），队列长度（qLen），发送字节数（tx字节）和链路带宽容量（B）的信息。当接收方获取数据包时，它会将记录的所有元数据复制到ACK消息中发送回发送方。每次收到带有网络负载信息的ACK时，发送方决定如何调整其流速。
显然：HPCC的思路仍然是全网更紧密的配合，以达到“网络不丢包”的目的，HPCC的交换机与网卡的耦合加深了。
（4.6）我对RoCE的设计思路的看法
靠全网的紧密配合来应对局部风险，一点拥塞，多点流控。其后果是任何局部风险，一旦处理失败，就可能上升为系统性风险。
其实分布式系统能容忍任何一个局部的彻底故障，但不能容忍整个网络在同一时间一起流控。当局部出现问题时，及时隔离有问题的局部，避免局部拖累整体才是有韧性的设计思路。
最后回答开篇提出的第二个问题：RoCE“不允许网络丢包”这种要求合理吗？
我认为：
如果在封闭内网内，如果集群规模也不大，那无损网络的要求就是合理的。
如果在开放网络上，尤其是跨地域的通信，那无损网络的要求就不现实。
因此，RoCE虽然风险不少，但是在高性能的封闭内网中仍将占据一定位置。
