TL;DR

其实几个月前就知道OpenAI和Nvidia / AMD / BRCM / Intel在搞一个新的RDMA协议, 昨天见到了OCP的白皮书《Multipath Reliable Connection (MRC) Specification》^[1], 以及OpenAI官网的一个发布blog 《Supercomputer networking to accelerate large scale AI training》^[2]. 本来这个问题我们已经完美解决了, 阿里云所有Region所有AZ从第八代计算实例开始就完全支持, 多路径都上线2年多了.... 但看到这个协议还是有那么多缺陷, 起初真是懒得多说话了, 但耐不住一堆人来问, 干脆又得罪人来锐评一下.

总体来说, 这个Multipath Reliable Connection (MRC) 的名字定义是准确的, 要在RC Verbs生态兼容的情况下做好多路径的能力, 至少这件事情终于想清楚了,  没有像 AWS 那样搞什么 SRD 或者 UEC 去搞Libfabric的接口, 这正是我几年前就一直在说支持兼容RC Verbs接口的多路径 Lossy RDMA才是正路, 苦口婆心没人听...还记得某些人前几年张嘴就来“ OpenAI RoCE用的好好的, 哪来的问题”, 既然没问题, 那搞新的协议干嘛?

1. 从RDMA现代化谈起

对于不熟悉这块知识的读者, 可以看以下以前写的一篇比较好懂的文章《“漫”谈RDMA现代化》 来了解 ScaleOut RDMA, 特别是RoCE遇到了哪些问题. RDMA现代化主要是解决以下两个难题:

这也是 MRC 协议覆盖的内容, 也是我一直讲的要支持 RC Verbs 生态兼容, 支持 Lossy RDMA, 支持多路径... 下面这个决策图用了好多遍了, 终于看到这几家想清楚了...

但是很遗憾的是, 他们并没有完全搞明白该怎么做, 例如还需要依赖交换机, 语义上也仅支持 WRITE 和 WRITE_IMM, 那么SEND/RECV, READ, ATOMIC呢? 又不是做不了, 还不是能力不行...

2. 详细分析MRC

2.1 Overview

MRC Spec里写的挺清楚的针对AI/ML 作负载在标准尽力而为以太网上提供可靠的, 高有效吞吐量的连接. MRC 扩展了 RC 传输协议, 具备显式的多路径操作, 路径健康监控和故障恢复能力, 从而使端点能够在拥塞, 链路故障和其他网络损伤的情况下维持有效的吞吐量. 在更大的系统栈中, MRC 位于现有协议层与 AI/ML 框架或运行时库之间, 暴露的 API 允许 NIC, 加速器和主机软件利用多个网络路径, 同时在需要时保留有序的, 可靠的交付语义.

MRC 解决了诸如网络容量利用率不足, 因瞬时网络问题导致的作业失败或停滞, 以及端点行为与特定网络拓扑的紧密耦合等问题.

简单来说做了以下几方面改进, MRC 连接实现了以下核心能力:

• 多路径传输 (Multipath Transmission): 使用 ECMP 或源路由, 将请求和可靠性控制数据包 (SACKs) 分布到多个网络路径上, 并支持 ECN 标记.
• 可靠性控制 (Reliability Control): 使用选择性确认 (SACKs) 和否定性确认 (NACKs) 来确保及时的数据包交付并传达拥塞状态.
• WriteIMM 限制 (WriteIMM Limiting): 强制执行用户定义的每个连接中在途的带立即数写操作 (Write-with-Immediate) 的最大数量.
• 拥塞控制 (Congestion Control): 实现 NSCC, 一个在 UltraEthernet 传输规范 [UESPEC] 中指定的基于发送端的拥塞控制算法.
• 选择性重传 (Selective Retransmission): 允许基于 SACK/NACK 反馈重传特定的数据包.

2.2 如何支持多路径

从转发路径上来看, 包括两种实施方案:

1. 基于熵值的请求包轮换, 和Google PLB类似利用IPv6的额外的flowlabel字段作为路径熵影响交换机ECMP hash.
2. 或者使用SRv6这些source-routing的技术, 让交换机跟着uSID寻址转发.

2.3 为什么语义上MRC仅支持 WRITE/WRITE_IMM

语义层面, MRC在标准的RoCE基础上增加了一个OPcode. 然后通过在每个消息中携带RETH Header来实现Direct Data Placement(DDP)能力.

但是很遗憾, 它只支持WRITE, WRITE with Imm... SEND/RECV, READ, ATOMIC都不支持...

2.3 拥塞控制

主要是借鉴AMD/BRCM在UEC提的那一套:

1. 增加独立的SACK能力,  SACK 传达数据包接收状态以及为传输和拥塞控制 (CC) 算法提供的网络和响应端拥塞信号.
2. 基于PSN的Window based CC,  响应端可以在运行时调整最大在途数据包的范围.
3. 毕竟Intel在里面, AMD也有以前在Intel搞NDP的, 还有BRCM的也是喜欢NDP, 所以Packet Trim也被包含进来了
4. 还是采用Active probe的机制, 并且可以根据Entropy Probe某个路径, 最后可达性信息还可以通过Port Status mask传递.

3. 结论

大概就这样吧, 也数落了MRC不少的问题了... 本来我都懒得谈这事了, 几年前就干净解决的问题, 几大厂商如今还在这里折腾, 折腾废了UEC, 又开一个新的MRC坑...然后还是解决不干净, 就是一个很脏的工程补丁... 极度无语...

很大程度上他们都被Nvidia CX系列的微架构束缚着. 我还是老话重谈, 下面几个指标是几年前提出的, 做到了再来说话...几个指标如下:

1. 集合通信能够保证95%以上的Fabric利用率 ✅MRC应该能实现
2. 丢包率5%的时候仍然能够保证90%的Goodput  ❓没有测试结果, 理论上MRC可以做,但是受到Inflight限制
3. 无需任何交换机的高级特性, 网卡实现多路径和拥塞控制 ❌MRC需要依赖交换机, 多路径可能要SRv6的能力, 拥塞控制要ECN和NDP
4. 超大规模(128K QPs)并支持所有QP开启多路径转发能力. ❓这个和具体网卡微架构实现相关
5. 兼容RDMA RC Verbs, 线下RDMA应用无需修改代码即可直接运行. ❌坚持RC兼容是MRC作出的正确选择, 但是也是只支持部分语义算个怎么回事?
6. Incast 128打1这样的场景, 每个QP之间的带宽差额最大100Kbps.❓基于Window Based CC应该可以, 但是实现上还需测试

感兴趣, 自己读读《RDMA》这个专题, 了解更多的内容..

总体来说, 我还是要对MRC能够迈出在RC Verbs兼容的前提下, 支持多路径转发同时支持Lossy RDMA这件事点赞的. 三年前我们的选择成了工业界的共识, 但愿以后别再又折腾些Lossless的事情了... 然后...剧透一个小事情, 留给NV的时间不多了......