AI 传输中的包序、事务序与完成边界
从 Falcon、MRC 与 SUE-T 的包路径理解可靠性状态、乱序放置和资源回收
沿四包写操作的丢包恢复路径,比较三种传输对包收到、操作处理与软件完成的不同定义,解释选择性重传、有序交付及死锁避免的资源成本。
可靠传输的设计起点是定义一次完成所覆盖的范围。网络可以确认一个包已经抵达,内存子系统可以确认数据已经放置,上层协议还需要决定操作何时对软件可见。这些事件的先后关系决定重传缓冲何时释放、乱序数据存在哪里、连接错误是否必须终止整项工作。Falcon、MRC 与 SUE-T 给出了三种有代表性的组合:多协议事务传输、面向 RDMA 写的乱序直接放置,以及面向 Scale-up 内存事务的轻量有序交付。S039 pp. 10–14 S040 pp. 25–31 S041 pp. 13–20
把包序、事务序与完成序拆开#
Falcon 在上层协议与网络之间设置事务子层和包交付子层。一个 ULP Operation 可以映射为多个 Falcon 事务;事务以 RSN 标识,包以 PSN 标识。Read 和 Atomic 映射到 Pull,Send 和 Write 映射到 Push。事务层负责资源与事务排序,包层负责可靠交付、拥塞控制和多路径。发起方与目标方描述事务角色,发送方与接收方描述包角色:发起一次 Read 的节点先发送请求,再接收返回数据。S039 pp. 10–15
这套分层允许两种顺序同时存在。有序连接在目标端把 Pull Request 与 Push Data 按 RSN 合并排序后交给 ULP;在发起端,把返回的 Pull Data 与 Push 完成事件按 RSN 合并排序。网络中先收到哪个 PSN,由包层记录;上层先看到哪个事务,由事务层决定。无序连接则解除这组事务排序要求,交由对应 ULP 组织自己的依赖。S039 pp. 55–61
MRC 选择了更专门的语义集合:Write 和 Write-with-Immediate。每个数据包均带有足够的远端地址与访问权限信息,接收端可以跨消息乱序接收并把载荷直接放入目标内存。每包 RETH 的虚拟地址随 PMTU 前进,r_key 在同一消息内保持一致,DMA length 描述整个 Work Request。这样,包的物理到达顺序与消息内偏移计算解耦,接收端以元数据跟踪缺口,减少为了恢复网络顺序而缓存完整载荷的需求。S040 pp. 19–26
完成序仍然受到严格约束。请求端 Work Request 按提交顺序完成;目标端 WriteIMM 完成必须等待所有前置请求收到并处理,并按发送顺序产生。可以构造一个工程例子:先写数据块,再发送带 Immediate 的通知;数据块分片可乱序落位,通知完成只在前面的写与本次写均放置后出现。使用者依靠这个完成点推进下一阶段,同时接受前置 Write 之间没有独立的放置顺序保证。S040 pp. 21, 26–27
一个缺口如何穿过整条写路径#
Falcon 的四包写示例把确认边界显示得很清楚。发起端把一项大于三个 MTU 的 Write 拆为四个 Push,RSN 为 1–4,PSN 为 300–303。包 300 丢失,后面三个包到达。目标包层知道它们已经收到,有序事务层仍等待 RSN 1。EACK 回传 Data Rx Bitmap=1110b,发起端补发 300,随后目标按序向 RDMA 引擎提交四个请求。RDMA 引擎完成写入并回报后,目标才能发出覆盖这些 Push 的 ACK,发起端再组织最终 Write completion。S039 pp. 27–28
阅读原图时,沿中间两列观察 EACK、补发 PSN 300 和最终 ACK 的位置,再看右侧 Write Memory 与 Push Completion:网络缺口补齐之后,上层执行与最终确认还有一段独立路径。

原图:S039,物理第 27 页,Figure 13;步骤说明续至第 28 页。
Falcon 因而给数据包保留 received 与 acknowledged 两种状态。Data Rx Bitmap 表示包进入接收端,Data ACK Bitmap 表示已达到对应确认边界。Push Data 的 acknowledged 必须等待目标 ULP 确认;Pull Request 与 Pull Data 在包交付阶段可直接确认。在线 EACK 分别携带 128 位 Data Rx、128 位 Data ACK 和 64 位 Request bitmap,包序号为 32 位。S039 pp. 32, 39–40, 62–63
重传算法使用 Rx bitmap 识别网络缺口,事务层处理 ULP 的拒绝或延迟。若只看到 ACK bitmap 的零位便补发,已经进入目标端、正在等待 ULP 的数据也可能被重复发送。Falcon 的早期重传因此检查同一路径的乱序距离,并要求距离上次发送至少经过一个 RTT,给此前发送或重传留出被确认的时间。多路径状态如何参与这个判断,见拥塞反馈与多路径。S039 pp. 69–71
MRC 把同类边界放进两类控制消息。Reliability SACK/NACK 描述包交付和拥塞状态,RDMA Transport ACK/NAK 描述上层语义结果。一个包可以已经被可靠性 SACK 确认收到,随后在语义层被 NAK 拒绝。发送端可用传输层结果推导相应包的接收情况,而操作处理结果必须由对应语义控制消息给出。这直接影响 NIC 中释放重传副本、释放 WR 与向 CQ 提交完成的各个时点。S040 pp. 27, 30–31
可靠性状态的成本落在不同位置#
| 设计维度 | Falcon | MRC | SUE-T |
|---|---|---|---|
| 上层工作单位 | Push/Pull 事务承载 RDMA、NVMe 映射 | Write、WriteIMM 的 WR 与包 | Load/Store/Atomic 命令及响应 |
| 网络可靠性单位 | 两个 PSN 空间中的包 | QP 中的 24 位 PSN 包 | RODL PDC 中的包,可打包多个命令 |
| 乱序处理 | 包接收状态与事务 RSN 重排 | 跨消息接收跟踪、乱序直接放置 | 有序交付;出现意外 PSN 后等待缺包 |
| 确认语义 | Push ACK 与目标 ULP 确认关联 | Reliability SACK 与 Transport ACK 分离 | Delivery ACK 或 Operational ACK |
| 恢复方式 | 选择性早期重传、超时、Resync | SACK/NACK 选择性重传、探测 | 可选 GoBackN,依赖无损网络服务 |
| 接收端暂不可用 | 支持 ULP RNR 及事务重试 | 资源压力反馈与可靠性 NACK;无 RNR-NAK | 接口信用、PFC/CBFC 与实现配置 |
矩阵依据:S039 pp. 10–18, 62–71 S040 pp. 19–38 S041 pp. 10–22。
MRC 接收端的累计确认 cack_psn 标出第一个缺口之前的连续前缀,跟踪窗口容纳后续乱序包。每个 SACK 只回传其中一个 64 位片段,再用相对 cack_psn 的偏移定位。最大 PSN 跨度 MPR 以 128 包为编码单位;因此,一个 SACK 的位图片段与整个接收跟踪能力具有不同规模。低序号优先的片段选择有助于发送端释放老资源,同时随着片段轮转报告更靠后的包。S040 pp. 36–43, 48–49
SUE-T 则把状态节省放在优先位置。它面向单交换机跳数的 Scale-up,将多个内存命令打包后,通过 UET RODL 有序传递。使用 GoBackN 时,接收方发现意外 PSN 就 NACK 并丢弃后续包,直至预期序号到达。端点省去了选择性接收位图与复杂选择性恢复状态,相应地承担更大的丢包恢复代价。规格还允许省略传输重传,以进一步缩减缓冲;这种实现一旦出现残余包丢失,连接就会失败。S041 pp. 13, 19–22
顺序约束必须进入死锁分析#
可靠性协议的资源图与顺序图互相制约。Falcon 的 Push ACK 依赖 ULP 接受,而 ULP 接受可能在等待更早的 RSN。若请求与响应竞争同一批缓冲,已进入系统的请求可能占满本应用于产生响应的空间,响应无法返回,旧请求又无法释放。Falcon 为此把 Pull Request 与数据分成两个滑动窗口,分别管理输入和输出资源,并要求同方向上由 initiator 与 target 生成的包独立前进。S039 pp. 45–49
发出 Pull 时,发起端提前留出接收返回数据所需的资源。目标端还要为队首事务保留进展机会:接收池处于绿色区域时可接纳普通请求,进入红色区域后只接纳 HoL 请求。事务调度至少在事务类型和连接两层进行轮询。有序连接的初发与重发均需遵守跨请求、数据窗口的 RSN 顺序。这些规则把“可靠”落实为资源受限时仍能完成的协议。S039 pp. 49–55, 67–71
SUE-T 的对应约束是请求与响应分配到不同流量类别,一个虚连接至少需要两个 TC。MRC 则在软件接口上明确 WriteIMM 在途数量与接收 descriptor 的责任:接收端暂存 Immediate Data 的容量由 max_wimm_inflight 给出,软件必须限制未完成操作数量;若完成无法交给 RQ,QP 进入错误状态。这三种设计分别把活性约束落在事务资源池、流量类别与软件资源预留上。S041 pp. 18–20 S040 pp. 26–29
重复包和旧包还要通过连接身份检查#
可靠性状态也用于处理反向 ACK 丢失。发送端可以从后续累计确认恢复进度,或在包定时器到期后再次发送;接收端识别此前已确认的重复包,丢弃重复载荷并回传确认。接收端的去重状态和发送端的重传状态必须对同一连接身份保持一致,连接复用与序号回卷也因此需要额外保护。S039 pp. 63–64, 78–79, 104–105
Falcon 使用 PSP 或 IPsec ESP 对连接数据认证加密,并通过方向性安全关联、SPI 和时间戳限制旧包被错误接纳。时间戳保护窗口允许此前发送却因网络乱序而延迟的包进入,同时要求窗口显著小于最短 PSN 回卷时间。密钥轮换时保留新旧 SPI 的重叠接收阶段;安全检查失败的包不会产生 ACK/NACK。由此,恢复算法所依据的位图和确认消息也处在连接安全检查之内。S039 pp. 19, 75–78
错误完成与资源回收构成最后一段协议#
Falcon 对暂时性拒绝和永久性操作错误采取不同路径。Push 遇到 RNR,由发起端按照返回等待时间重试;Pull 的请求已经得到包确认,目标端自己保留请求并在 RNR 等待后重新交给 ULP。遇到 CIE,发起端以 Resync 填补原 PSN 的逻辑缺口,接收方推进窗口,随后向上层报告该事务错误,使连接上的后续事务继续前进。S039 pp. 18, 22–26, 57–62
资源回收又需要两个时钟。包重传时钟覆盖网络包与 ACK 的丢失;事务时钟覆盖请求已经确认、响应却迟迟未生成的情形。规范建议事务层回收超时显著长于包层回收超时,减少 Tx/Rx 资源竞争释放的风险。工程实现应为每种状态明确持有人、完成触发与兜底清理路径,使一次断链最终能够释放滑动窗口位置、数据副本、接收预留和上层等待者。S039 pp. 103–107
因此,选型时最有解释力的交付物是一条完整失败路径:丢一个包后,哪个状态先变化,哪个反馈回去,发送端保留哪些信息,目标内存是否已改变,上层看到什么完成,最后谁清理资源。Scale-up Ethernet进一步展开小事务与确认压缩的取舍;Fabric 运维把这些状态接到故障隔离与维护流程。