# NetSoft 2021《In-Network Applications: Beyond Single Switch Pipelines》中文译注与分析

**Source:** Xin Zhe Khooi, Levente Csikor, Jialin Li, Dinil Mon Divakaran, *In-Network Applications: Beyond Single Switch Pipelines*, IEEE NetSoft 2021.
**URL:** https://www.comp.nus.edu.sg/~lijl/papers/netapp_tapopf21.pdf
**DOI:** 10.1109/NetSoft51509.2021.9492665
**Pages:** 8
**Notes date:** 2026-04-28

本文是面向 OpenUSim / UBody 建模讨论的中文精读译注和分析，不是论文逐字全文翻译。重点保留论文的论证结构、多 pipeline 交换机公开事实、有状态数据面应用的失败模式、workaround，以及对 `UBody` 建模边界的启发。

---

## 1. 论文定位

这篇论文不是提出一个新的交换机硬件，也不是提出完整可部署系统。它是一篇 problem / position paper，核心目标是提醒社区：大量 in-network application 默认交换机只有一条 pipeline，但真实 commodity programmable switch 经常是 multi-pipeline 架构。这个差异会让很多有状态数据面应用在实际部署时行为错误或代价很高。

论文的价值在于：

- 明确指出 commodity programmable switches 常由多条 packet processing pipelines 组成。
- 明确指出 pipeline 通常独立，并拥有自己的硬件资源，例如 SRAM。
- 明确指出 pipeline 间没有 coherent memory，某条 pipeline 的状态更新不会自动对其他 pipeline 可见。
- 用 TCP connection tracking 举例说明 request 和 response 如果经过不同 pipeline，有状态应用会失败。
- 分类分析多类 in-network applications，判断哪些能适配 multi-pipeline，哪些会失效。
- 总结几类 workaround，并指出它们都有性能、复杂度或一致性代价。

对 `UBody` 调研而言，这篇论文是强证据之一：它从学术角度直接描述了 multi-pipeline switch 的 pipeline-local resources、无跨 pipeline coherence、port-to-pipeline mapping、以及跨 pipeline traffic 的现实问题。

---

## 2. 摘要意译

论文摘要的大意是：

可编程交换机让传统上偏无状态的网络数据面可以承载有状态逻辑，例如网络监控、负载均衡、防火墙等。很多已有 in-network applications 假设底层交换机是 single-pipeline，但实际 commodity programmable switches 通常按 multiple pipelines 设计。多 pipeline 能提升扩展性，但也带来严重问题：跨 pipeline 维护状态很困难。比如 request 和 response 经过不同 pipeline 时，如果不借助控制面，数据面很难跟踪它们之间的关系。

作者认为，这个限制会妨碍有状态 in-network applications 在真实 multi-pipeline switches 上广泛部署。论文回顾近期若干 in-network proposals，指出多数方案无法按原始设计直接运行在 multi-pipeline switches 上。之后作者讨论了一些可行 workaround，但也强调这些 workaround 都有明显代价。

关键词包括：

- stateful applications
- programmable switches
- multi-pipeline
- software-defined networks

---

## 3. 引言精读

论文开头指出，可编程交换机让网络数据面出现了大量新应用，例如：

- 网络监控。
- 流量工程和负载均衡。
- 高精度拥塞控制。
- 异常检测。
- DDoS 防御。
- 分布式协调。
- 分布式机器学习聚合。
- in-network caching。

这些应用能够把一部分原本在端主机或控制面完成的逻辑卸载到交换机数据面，从而降低延迟或提高吞吐。其中关键前提是：programmable switch 暴露了 registers、meters、counters 等有状态组件。

但论文强调，这些有状态资源并不充裕，而且真实交换机为了扩展 backplane capacity，通常会有多条 packet processing pipelines。作者给出的公开范围是：从 1 条 pipeline / 16 个端口，到 4 条 pipelines / 64 个端口。

引言中的核心论点：

- pipeline 为了扩展性能而独立存在。
- 每条 pipeline 有 dedicated hardware resources，例如 SRAM。
- pipeline 之间没有 coherent memory。
- 某条 pipeline 中的状态更新不会自动对其他 pipeline 可见，除非显式同步。
- 真实流量会根据交换和路由策略跨 pipeline。
- 因此，应用开发者必须显式处理分布在多个 pipeline 上的状态。

这也是论文的主问题：很多 in-network applications 其实隐含假设 request、response、probe、update 等相关 packet 会经过同一条 pipeline；一旦相关 packet 分散到不同 pipeline，状态就会不一致或不可见。

---

## 4. 背景：Programmable commodity switches

论文第二节先概述三类相关交换机 pipeline 架构：

- PSA：P4 Portable Switch Architecture。
- PISA：Protocol-Independent Switch Architecture，例如 Intel / Barefoot Tofino。
- FleXGS：Broadcom Trident 系列相关架构。

### 4.1 PSA pipeline

PSA 中典型 pipeline 包含三个主要部分：

- ingress。
- packet replication engine。
- egress。

Ingress 和 egress 各自有 parser、deparser 和 match-action units。论文特别指出：每条 pipeline 会映射到一组 switch ports。

这点对 `UBody` 很重要，因为它和我们当前 `body owns local ports` 的建模假设同向。

### 4.2 PISA pipeline

PISA pipeline 通常包括：

- ingress blocks。
- egress blocks。
- 多级 match-action stages。
- ingress 和 egress 之间的 traffic manager。

PISA 允许 stateful packet processing，例如通过每级 SRAM 暴露 registers。

### 4.3 FleXGS pipeline

FleXGS 架构同样包含 programmable ingress / egress pipelines，以及多级 lookup engines。它还有类似 PISA traffic manager 的 memory management unit。

论文提到一个区别：FleXGS 中 packet parsing 和 deparsing 只做一次，而 PISA / PSA 风格里 ingress / egress 都可能有自己的 parser / deparser 结构。

### 4.4 共同硬件限制

论文总结这些架构为了维持 line-rate forwarding，通常有一些共同限制：

- 每条 pipeline 的 stage 数量有限，例如 Tofino 约 12 级，Trident 3 约 5 级。
- 每级可用 memory 固定。
- 并行 memory access 数量固定。
- ALU 操作集合较简单。

这说明：pipeline 内部资源是明确受限的，不能被当成无限共享池。

---

## 5. 背景：Multiple switch pipelines

这是全文对 `UBody` 最关键的背景部分。

论文解释 multi-pipeline 的动机：

- ASIC packet processing rate 受 clock rate 约束。
- 与其提高单条 pipeline clock 或资源，不如 scale out，增加 parallel pipelines 数量。
- 每条 pipeline 管理一组不重叠的 physical ports。
- 多条 pipeline 除了通过 switch backplane / traffic manager / memory management unit 连接外，不共享 SRAM、TCAM 等常用资源。

论文进一步指出：

- 应用部署到 multi-pipeline switch 时，通常需要在每条 pipeline 上分别部署。
- packet 可能通过 backplane 从一条 pipeline 切换到另一条 pipeline。
- 某条 pipeline 中维护的 counters / registers 等 state，不会同步、共享或被其他 pipeline 直接访问。
- 因 routing / switching，自相关状态可能散落在多条 pipeline 中。

这段可以抽象为一个公开架构事实：

```text
pipeline = local ports + local hardware resources + local state,
cross-pipeline traffic = explicit path through switch backplane / traffic manager,
cross-pipeline state coherence = not automatic.
```

这和 `UBody` 的公开建模非常接近：

```text
UBody = local ports + body-local NetworkUnit + body-local resources,
ForwardToBody = explicit cross-body path,
cross-body resource sharing = not implicit.
```

---

## 6. 示例：TCP connection tracking

论文用 TCP conntrack 展示 multi-pipeline 下有状态应用如何失败。

### 6.1 应用逻辑

TCP conntrack 在防火墙中常见。它要求：

- 内部 host 发出的 TCP SYN 必须先被观察到。
- 后续外部 server 返回 SYN-ACK 时，防火墙检查这个连接是否确实由内部发起。
- 如果没有看到过内部发起的 SYN，外部发起连接应被拒绝。

数据面实现通常会用 Bloom filter 或类似概率数据结构，把 outgoing SYN 的 flow ID 记录到 pipeline SRAM / register 里。返回 SYN-ACK 到达时，用反向 flow ID 查询 Bloom filter。

### 6.2 同 pipeline 情况

如果 Host A 和 Server 连接在同一条 pipeline 上：

- Host A 的 SYN 进入 pipeline 0。
- pipeline 0 的 Bloom filter 记录该 flow。
- Server 返回 SYN-ACK 也进入 pipeline 0。
- pipeline 0 能查询到之前记录的状态。
- 连接通过。

这个场景下有状态应用正常工作。

### 6.3 跨 pipeline 情况

如果 Host B 位于 pipeline 1，而 Server 位于 pipeline 0：

- Host B 的 SYN 进入 pipeline 1。
- 连接状态被记录在 pipeline 1 的 Bloom filter。
- Server 返回 SYN-ACK 从 pipeline 0 进入。
- pipeline 0 的 Bloom filter 没有这条 flow 状态。
- SYN-ACK 会被错误丢弃。

论文由此归纳出核心后果：

有状态应用如果依赖之前 packet 留下的状态，而相关 packet 又经过不同 pipeline，就不能按原设计工作。

### 6.4 对 UBody 的启发

对 OpenUSim 而言，这个例子可以直接转化为 body-local state 的建模原则：

- 如果状态属于某个 `UBody`，另一个 `UBody` 不应默认直接访问。
- request / response 可能经过不同 body，因此必须明确状态 owner。
- 如果需要跨 body 查询状态，需要显式 `ForwardToBody`、状态复制、IoDie 聚合或控制面同步。
- 对有强一致性要求的状态，不应简单用异步复制模拟。

---

## 7. 应用分类分析

论文第四节把 recent in-network proposals 分为两类：

- Networking。
- In-network compute & acceleration。

作者逐类分析这些应用在 multi-pipeline switch 上是否会失效。

### 7.1 Network monitoring

网络监控类应用记录 packet / byte 计数、heavy hitter、cardinality、queue measurement 等。

作者认为，多 pipeline 对很多网络监控应用影响较小，原因是：

- 它们多是统计类数据。
- 不依赖 request / response 这种严格相关的先验状态。
- 即使统计散落在不同 pipeline，控制面最终可以聚合。
- 这些统计通常有可交换 / 可聚合特性。

INT 也被认为较容易适配，因为 queue occupancy、link utilization 等信息通常在 egress pipeline 当地可用。

对 `UBody` 的启发：

- per-body counters 可以先局部维护，再由 IoDie / post-analysis 聚合。
- 监控类数据不一定需要强 cross-body consistency。
- 适合做成 body-local metrics + global aggregation。

### 7.2 Load balancing

HULA、MP-HULA、DASH、Contra 等动态负载均衡方案依赖 probe，把链路利用率、queue occupancy 等实时状态写入 ingress pipeline 的 registers，再由后续流量查询这些状态选择路径。

问题是：

- 如果目标 egress link / port 属于另一条 pipeline，当前 ingress pipeline 可能收不到对应 probe 状态。
- ingress pipeline 缺少目标 link 的相关状态。
- 因而无法正确执行动态负载均衡决策。

对 `UBody` 的启发：

- 如果 body-local routing decision 依赖其他 body 的 queue / utilization，需要明确状态同步或集中视图。
- 不能默认 `UBody` 可以读到所有 body 的实时拥塞状态。
- `ForwardToExternalPort` 的 routing/admission owner 必须明确：本 body 决策、目标 body 决策、还是 IoDie 统一决策。

### 7.3 DDoS defense

DIDA 和 Poseidon 这类数据面 DDoS 防御需要同时统计 request 和 response。例如 DNS amplification attack 中，响应数显著多于请求数时可能判定为攻击。

如果 request 和 response 到达不同 pipeline：

- 单个 pipeline 看不到完整 request / response 对。
- 可能误判正常响应为攻击。
- 除非控制面介入或状态同步，否则数据面无法正确判断。

对 `UBody` 的启发：

- 需要配对 request / response 的状态，不能随意分布。
- 如果某类状态要求关联两个方向，应绑定到明确 body owner，或通过 IoDie 统一管理。

### 7.4 In-network caching

NetCache 这类缓存方案把热门对象缓存到交换机数据面。

论文认为 NetCache 可以适配 multi-pipeline，原因是：

- 对某个对象的请求总是发往保存该对象的 storage server。
- storage server 的 egress port 稳定。
- 对象 cache 可以放在对应 egress pipeline。
- 不管请求从哪个 ingress 进入，都会被导向同一个 egress pipeline。

对 `UBody` 的启发：

- 如果状态能按 destination / owner 稳定归属到某个 body，multi-body 设计可以工作。
- `UBody` 适合表达 “state owner follows egress body / target resource” 的策略。

### 7.5 Distributed coordination

论文分析 NOPaxos、Eris、NetChain、NetLock、Pegasus 等分布式协调或存储系统。

NOPaxos 和 Eris 依赖 ordered multicast，需要在交换机里维护序列号。问题是：

- multicast packet 可能从任意 ingress pipeline 进入。
- 序列号如果放 ingress pipeline，无法保证所有入口看到同一个状态。
- 如果放 egress pipeline，multicast 又可能复制到多个 egress ports，要求所有 copy 有相同序列号。
- 因此 multi-pipeline 下难以保持 required ordering semantics。

NetChain 和 NetLock 相对可行，因为它们把 key-value 或 lock table 维护在对应 egress pipeline；query / update 会稳定路由到同一个 egress pipeline。

Pegasus 会失败，因为它的 coherence directory 需要 request 和 reply 访问同一个 entry；但 request 和 reply 可能由不同 ingress / egress pipelines 处理，无法获得一致 directory view。

对 `UBody` 的启发：

- 强一致性状态必须有清晰的 owner。
- 如果状态 owner 不能由 destination 稳定决定，就会出现跨 body 一致性风险。
- 对 linearizability / strict serializability 这类强语义，异步复制或多 body 分散状态通常不够。

### 7.6 Distributed machine learning training

SwitchML 在交换机内做分布式机器学习聚合。由于模型大，聚合通常是 streaming per-packet aggregation，聚合值存在 pipeline SRAM 中。

论文指出：

- 所有 worker 必须连接到同一 pipeline，才能在同一个 SRAM 状态上聚合所有更新。
- 这限制了 SwitchML 在 multi-pipeline switch 上扩展。
- 作者后续讨论层次化组合等 workaround。

对 `UBody` 的启发：

- 聚合型状态如果要跨 body 工作，需要层次化 aggregation 或显式 reduction path。
- 不能假设所有 body 共享同一个 aggregation buffer。

---

## 8. Workarounds 精读

论文第五节总结了几类 workaround。作者整体态度是：这些办法能让部分应用跑起来，但都不是免费方案。

### 8.1 拓扑特化：把相关节点接到同一 pipeline

最直接办法是按 ASIC pipeline-to-port mapping 设计拓扑，让相关节点接到同一 pipeline。例如 TCP conntrack 中，只要 host 和 server 在同一 pipeline，状态就不会跨 pipeline。

优点：

- 实现简单。
- 不需要复杂同步。
- 可以把 multi-pipeline switch 当成多个 single-pipeline switch instances。

缺点：

- 受每条 pipeline 端口数限制。
- 大规模数据中心中，一个 rack 的 server 数可能超过单 pipeline 端口数。
- 会限制拓扑灵活性和负载均衡。
- 对缓存、coherence directory 等希望服务整个 rack 的应用不友好。

对 `UBody` 的启发：

- body-aware topology 是可行但受限的优化。
- OpenUSim 需要支持显式 body-port mapping，便于研究这种约束对 workload 的影响。

### 8.2 层次化组合

SwitchML 等方案可以把多个 pipeline 当成多个独立 switch，然后通过上层 aggregation switch 做二级聚合。

例如：

- ToR switch 的 4 条 pipeline 分别作为 4 个 disjoint switch。
- 各 pipeline 先做局部聚合。
- 再把局部结果送到上游 aggregation switch 做全局聚合。

优点：

- 可以跨多个 pipeline / rack 扩展。
- 局部状态仍保留在本 pipeline。

缺点：

- 增加路由和控制复杂度。
- 高可用和多上联负载均衡会让“同一流量总是经过同一上游路径”变难。
- 如果上游 switch 自己也有多 pipeline，问题可能再次出现。

对 `UBody` 的启发：

- 多 body 可采用 local aggregation + IoDie/global aggregation 的层次结构。
- 但要明确每级 owner 和路由约束。

### 8.3 Packet recirculation：把流量重定向到状态所在 pipeline

另一种办法是把 packet recirculate / re-inject 到拥有相关状态的 pipeline。

以 TCP conntrack 为例：

- Host B 的 SYN 状态在 pipeline 1。
- Server 返回 SYN-ACK 从 pipeline 0 进入。
- 可以把返回流量从 pipeline 0 recirculate 到 pipeline 1。
- pipeline 1 查询 Bloom filter 后再转发。

优点：

- 不复制状态。
- 查询发生在状态 owner 所在 pipeline。

缺点：

- 数据面程序需要额外 routing logic，知道哪些 packet 要被送到哪个 pipeline。
- packet 被 ASIC 处理多次，会消耗额外 processing / backplane capacity。
- 对 TCP conntrack 这种所有后续返回流量都要检查的应用，可能近似减半可用处理能力。

对 `UBody` 的启发：

- `ForwardToBody` 是合理抽象，但不是免费路径。
- 跨 body 查询状态应计入延迟、带宽和可能的队列竞争。
- 如果所有返回 traffic 都要跨 body 查询，性能影响必须在仿真里可观测。

### 8.4 跨 pipeline 复制状态

也可以把状态更新 packet mirror / recirculate 到其他 pipelines，让各 pipeline 复制一份状态。

适用场景：

- Bloom filter。
- sketch。
- 其他更新操作可交换、可合并的数据结构。

不适用场景：

- hash table，碰撞可能破坏状态。
- 需要强一致性或线性化语义的应用。
- 依赖严格操作顺序的 distributed coordination。

原因是 replicated packets 到达其他 pipeline 的顺序和时间不确定，不能保证 linearizability。

对 `UBody` 的启发：

- 对 body-local metrics，可以允许 eventual aggregation。
- 对强一致状态，不能简单复制。
- 应在模型里区分 commutative state 和 non-commutative state。

### 8.5 控制面回归

最后一种办法是让控制面重新介入。

例如 TCP conntrack：

- 数据面看到 SYN 后上报控制面。
- 控制面更新所有 pipeline 的 Bloom filters，或下发 match-action table entries。
- 这样所有 pipeline 都能看到同步后的状态。

优点：

- 能提供较明确的全局同步路径。
- 可作为复杂状态的一种保守方案。

缺点：

- 控制面介入带来额外延迟，论文引用其他工作指出可能到秒级。
- 背离“全部在数据面低延迟处理”的目标。
- 需要把控制面开销控制在可接受范围内。

对 `UBody` 的启发：

- IoDie / control plane 聚合 body-local 状态是合理后备路径。
- 但它不应被伪装成 line-rate body-local fast path。
- 模型需要区分 fast path 和 control-plane synchronization path。

---

## 9. 结论和开放问题

论文结论认为：

- multi-pipeline 是现代 commodity programmable switching ASIC 的重要属性。
- TCP conntrack 例子说明有状态应用很容易在 multi-pipeline switch 上行为错误。
- 多数 in-network applications 直接部署到 multi-pipeline switch 时无法按预期工作。
- workaround 存在，但都会带来性能、复杂度或一致性 trade-off。
- 作者认为当前没有 universal solution 可以让所有有状态应用完全在 multi-pipeline data plane 中正确工作。

论文提出的开放问题包括：

- 是否存在完全在数据面同步 pipeline states 的算法？
- 如果存在，它能提供什么一致性保证？
- 面向 multi-pipeline architecture，语言应提供什么构造和语义？
- P4 / NPL 这类 target-independent 语言是否应该具备 pipeline awareness？
- 未来硬件是否可能提供跨 pipeline coherent memory？

这和 OpenUSim 的建模方向高度相关：如果我们要显式建模 `UBody`，就不只是为了模拟时延，而是在暴露“局部状态 + 显式跨 body 路径 + 一致性/同步代价”这一类真实架构问题。

---

## 10. 对 UBody 的强支撑点

这篇论文对 `UBody` 的支撑主要有六条。

### 10.1 Pipeline-local resources 是公开事实

论文明确描述了 multi-pipeline switch 中每条 pipeline 有独立硬件资源，例如 SRAM / TCAM。这个点支撑 `UBody` 拥有 body-local resources。

### 10.2 Port-to-pipeline mapping 是公开事实

论文说明每条 pipeline 被设计和配置为管理一组不重叠的 physical ports。这支撑 `body -> ports` 的显式绑定。

### 10.3 Cross-pipeline traffic 是常态

论文强调 packet 会因 routing / switching 从一条 pipeline 进入另一条 pipeline。这支撑 `ForwardToBody` / cross-body egress 不是人为复杂化，而是 slice / pipeline 架构下必须面对的路径。

### 10.4 Cross-pipeline state coherence 不是默认能力

论文反复强调 pipeline state 不同步、不共享、不可被其他 pipeline 直接访问。这支撑 OpenUSim 不应默认 `UBody` 之间共享资源或状态。

### 10.5 Stateful applications 需要明确 state owner

TCP conntrack、load balancing、DDoS defense、Pegasus、SwitchML 等案例说明：如果 state owner 不清晰，应用就会错误或受限。对 `UBody` 而言，resource owner、routing owner、state owner 都需要显式。

### 10.6 Workaround 都有代价

拓扑约束、层次化、recirculation、状态复制、控制面同步都不是免费方案。这说明 `ForwardToBody` 后续需要建模带宽、队列、额外处理次数和控制面延迟，而不能只是逻辑函数调用。

---

## 11. UBody 映射表

| 论文概念 | OpenUSim / UBody 映射 |
| --- | --- |
| packet processing pipeline | `UBody` / body-local datapath slice |
| pipeline mapped to a set of ports | body owns local ports |
| dedicated SRAM / TCAM / registers | body-local resource limits and state |
| no coherent memory among pipelines | no implicit cross-body state sharing |
| switch backplane / traffic manager | `UbNetworkOnChip` / future body fabric |
| traffic traverses across pipelines | `ForwardToBody` / cross-body egress |
| recirculation to state owner | explicit cross-body state access path |
| state replication across pipelines | body-local state replication / eventual aggregation |
| control plane updates all pipelines | IoDie / control-plane synchronization |
| topology-specific wiring | body-aware topology / port mapping constraints |

---

## 12. 不能从该论文推出的结论

这篇论文不能支撑以下说法：

- `UBody` 是论文中的 pipeline。
- `UBody / BD` 是公开行业术语。
- 所有真实交换机 pipeline 都有相同资源、相同 stage 数或相同 port mapping。
- 所有 pipeline 都完全隔离；论文讨论的是 commodity programmable switches 的常见设计与问题，不是所有交换芯片的形式化定义。
- 论文给出了 cross-pipeline fabric / backplane 的精确微架构。
- 论文提供了可直接套用的 buffer depth、latency、bandwidth 或 arbitration 参数。

这篇论文真正支撑的是：

```text
multi-pipeline switch architecture, port-local pipeline ownership,
pipeline-local state/resources, absent default coherence, and explicit
cross-pipeline traffic/state workarounds are public academic concepts.
```

---

## 13. 建议写入 OpenUSim 公开文档的中文表述

```text
UBody 是 OpenUSim 中的 body-local 数据路径 / 网络切片抽象。公开 multi-pipeline
programmable switch 研究指出，真实 commodity switch 往往由多条 packet processing
pipeline 组成；每条 pipeline 管理一组本地端口，并拥有独立 SRAM / register 等资源；
pipeline 间没有默认 coherent memory，相关 packet 跨 pipeline 时，有状态应用必须显式
处理状态 owner、重定向、复制或控制面同步。OpenUSim 用 UBody 表达类似的本地端口、
本地资源和显式 cross-body path。
```

更保守的英文表述：

```text
UBody is an OpenUSim abstraction for a body-local datapath/network slice.
It follows public multi-pipeline switch modeling observations: pipelines own
local ports and local stateful resources, traffic may cross pipeline boundaries,
and state is not implicitly coherent across pipelines.
```

---

## 14. 对 OpenUSim 后续建模的具体建议

短期保持：

- `UBody` 继续作为 body-local `NetworkUnit` 边界。
- `body -> ports` 显式配置。
- `ForwardToBody` 保持显式 hop，不伪装成共享内存访问。
- body-local `IngressQueue / ContextBuffer / WriteBuffer` 不默认跨 body 共享。

中期可增加：

- `state_owner_body`：为需要 stateful processing 的对象标明 owner。
- `cross_body_state_access`：显式表达 packet/event 被送到 state owner body。
- `body_local_counter` 和 `iodie_aggregate_counter`：区分本地统计与全局聚合。
- `recirculation_cost`：跨 body 重定向导致的额外处理次数 / 时延 / 带宽消耗。
- `replication_policy`：区分 commutative state replication 和 strong-consistency state。
- `control_plane_sync_delay`：表达 IoDie / control plane 介入同步的延迟。

不建议：

- 不要把 `ForwardToBody` 建模成零成本函数调用。
- 不要默认所有 body 都能看到全局 queue / register / counter。
- 不要把 state replication 用于需要 linearizability 的场景，除非模型显式提供一致性协议。

---

## 15. 与 Cisco Q200 / PSA 资料的关系

这篇论文和前两份资料可以形成互补证据链：

- Cisco Q200 白皮书提供工业产品级 multislice ASIC 证据：slice、crossbar、VOQ、SMS、OQ。
- P4 PSA 规范提供规范级 multi-pipeline 证据：ports hard-wired to pipeline、pipeline-local state、output-port-driven egress pipeline。
- 本论文提供应用层和系统层证据：multi-pipeline 的本地状态和无 coherence 会让有状态 in-network applications 失败，因此显式建模 body-local state 和 cross-body path 是必要的。

三者共同支持：

```text
UBody 作为 body-local datapath/network slice 的公开仿真抽象有充分外部依据；
其关键价值不只是划分结构，而是暴露本地资源、跨 body 转发、状态 owner 和同步代价。
```

---

## 16. 一句话结论

这篇 NetSoft 2021 论文不是证明某个具体 `UBody` 硬件存在，而是从公开学术角度证明：multi-pipeline switch 的 pipeline-local ports、pipeline-local resources、无默认 coherent memory 和显式跨 pipeline workaround 是真实且重要的问题。它强力支撑 OpenUSim 将 `UBody` 建模为 body-local datapath/network slice，并在后续细化中显式表达 cross-body path、state owner 和同步代价。
