APNet'21：华为 UB：走向计算原生网络
这个 APNet 2021 上长达一小时的报告可能是目前公开的关于华为 UB（Unified Bus）总线的最好资料。
这篇图文实录是根据 APNet 2021 官方录像，使用 AI 技术生成的，并进行了少量的人工修正。这是自动翻译的中文版本，英文版本参见此处。
(主持人陈凯教授) 也许我可以先介绍一下 Kun。谭焜博士是华为中央软件院的副总裁，他在华为领导分布式和并行软件研究实验室。他的研究兴趣包括网络，网络系统和云计算。今天的讨论主题是 “走向计算原生网络”，这对一些人来说可能是一个新概念。
(谭焜博士) 大家好，感谢你的介绍。我很荣幸能够做今天的第一场演讲，主题是 “走向计算原生网络”。这对大多数人来说可能是一个新词，所以我会尝试解释它的含义和重要性。我认为这种新型的网络是我们应该关注的。
这是最近在华为与海思半导体合作进行的一部分工作。这是一种新型的网络技术。让我们来讨论一下它背后的动机。
我们可以从硅的发展中寻找灵感。摩尔定律正在放缓；我们已经达到了 7 纳米，现在是 5 纳米，但性能的提升速度并没有像以前那样快。然而，我们生成的数据量仍在指数级增长，从社交媒体到物联网。我们仍然需要更多的计算能力来处理和处理所有这些数据。
随着摩尔定律的放缓，我们发现处理这种数据量需要大规模的并行处理。我们不能依赖一个快速的芯片来完成这项工作。我们需要许多类型的处理器，组合在一起，因此我们可以扩展出像数据中心这样的架构。
我们面临的另一个挑战是需要异构处理。这意味着，如果我们无法提高单个处理器的速度，我们可能需要使用不同类型的处理器一起处理数据负载。
对更快的门的追求使我们设计了各种领域特定的架构。每一种架构都独特地适合处理某些类型的工作负载，从而产生了大量的领域特定架构，每一种都设计用来处理其相应的工作负载。
然而，这带来了一些挑战。首先，随着计算设备的增多和多样化，编译过程变得越来越复杂，有时甚至由于工作负载随时间的变化而变得无法克服。其次，我们发现设计服务器变得更加复杂。即使在单个服务器内，我们也有多种类型的处理器，这就需要一个能有效促进它们通信的连接。
不幸的是，当前的 I/O 架构在这方面表现不佳。
此外，应用程序的需求也在发展。以前，大多数应用程序都是由吞吐量驱动的，但现在延迟已经成为一个关键因素。不同的应用程序需要不同的延迟，大多数应用程序需要非常低的延迟，以微秒为单位。因此，即使是微秒级的延迟也会产生重大影响。
另一个趋势是一种新型存储的出现：存储级内存。这种字节寻址类型的内存访问延迟比 DDR 慢，但仍然比传统存储，如块存储，快。例如，英特尔的 3D XPoint 技术只有五微秒的访问延迟。然而，将这些大型内存银行连接到 CPU 成为了一个挑战。现有的 CPU 架构在内存互连方面的扩展性不好。目前，每个英特尔 CPU 只能支持几个内存通道。扩大这个容量是一个紧迫的问题。
总的来说，我们正在处理各种设备，每个设备都成为自己的计算实体。连接它们所有的互连的必要性是显而易见的。
不幸的是，当前的互连层次结构是不足的，呈现出性能和可扩展性之间的权衡。
如左图所示，我们有内存总线。内存总线被设计为直接连接到 CPU。虽然它非常快，但并不具有很好的扩展性。通常，一个内存通道只能连接到一个内存模块，形成点对点的连接。在另一端的是网络，其扩展性显著。我们可以在互联网规模上连接设备，但性能却不尽如人意。例如，当前的网络接口运行速度约为每秒 100 千兆字节，这比内存慢得多。位于中间的是像 PCIe 这样的本地 I/O 总线。
PCIe 的性能位于内存总线和网络之间，其可扩展性也是中等的。使用 PCIe，我们可以在一个盒子内连接少量的设备，但性能约为每秒 15 千兆字节。
在检查当前的连接层次结构后，很明显，它并不符合我们连接异构、大规模设备的目标。这导致了开发一种新型网络的想法，我们称之为”计算原生网络”。这是一种统一的、可扩展的连接，设计用来连接所有类型的设备，包括内存堆栈。
这是我们工作背后的基本思想和动机。经过一年的研究，我们开发了一个叫做”统一总线”的原型。
那么，为什么我们称之为”计算原生网络”呢？我们认为有三个属性定义了它。
首先，计算原生网络是一个内存语义网络。与传统的基于比特流且非 TCP 的网络不同，它应该支持加载和存储语义。这意味着每个设备，无论是处理器、内存模块、存储设备还是其他设备，都被视为一块内存。这些设备可以从一个内存位置加载数据，并在另一个位置存储数据。此外，它是统一的，因为其内存语义是计算系统内的通用协议。这就是我们所期待的。
所有设备都可以利用这种语义来执行各种类型的任务，使其成为一种高度通用的语义。我们可以定义一个单一的协议套件，连接到所有类型的 I/O 设备、处理器和其他组件。这也包括一个规模化的织物，它不是设计来连接一对或少数设备，而是连接数万个计算组件，从而形成一个大型集群。
上图说明了 CPU 使用标准加载和存储指令访问远程设备的概念。这些指令访问我们所说的 UB 内存接口，该接口将这些内存访问命令转发到远程设备。这些命令在远程 UB 中执行，就像访问本地内存一样。
如果我们检查 UB，我们可以预测 SoCs 或 CPUs 的有趣未来。当前的 SoCs 有各种不同类型的 I/O 引脚。有了 UB 的实现，我们预测 SoCs 只会有一种输出，即 UB。UB 为系统设计者提供了急需的灵活性，因为他们可以将这些端口重新用于不同的目标，不像当前的 SoCs，资源在制造阶段就被划分。
接下来，我将介绍一些 UB 使用的有趣例子。让我们首先讨论 UB 如何连接到远程存储。目前，在传统的存储系统中，我们有一个客户端（左图）和一个服务器（右图）。当前的系统是紧凑的，需要应用程序与操作系统一起工作。这增加了额外的数据复制，并有虚拟块的限制。
存储驱动程序使用 TCP/IP 通过 thislat 启动并转发这个存储访问。然后，请求由控制软件处理。本质上，控制软件作为服务器，将命令翻译为媒体的本地命令。随后，数据被写入存储。因此，在任务完成之前，涉及到多个软件和硬件层。目前，即使对于最高级别的存储系统，端到端的延迟也大约是 100 微秒。
然而，当我们实施统一总线（UB）时，情况会发生显著变化。一旦应用程序完成了配置认证，所有数据路径访问都会绕过操作系统。这就像访问本地内存一样，使得可以实现零拷贝。UB 提供超低延迟连接，只需要一微秒就可以访问远程媒体并直接写入数据。因此，整个延迟显著降低，标志着显著的改进。
UB 的另一个引人注目的用例是促进虚拟内存的共享。本质上，没有将内存划分为类别；不同的服务器可以贡献他们的内存形成一个共享的内存池。这允许其他 CPU 通过硬件辅助的通道直接访问内存。
这个内存池从整个系统的角度提供了几个好处。首先，它提高了内存利用率。一些应用程序可能以计算为中心，而其他应用程序可能以内存为中心。当内存资源被限制在单个服务器时，以计算为中心的应用程序可能有闲置的内存未被使用。然而，有了内存池，以内存为中心的应用程序可以更有效地利用这些备用容量。
其次，共享虚拟内存为应用程序提供了一个单一的地址空间。尽管内存是分布式的，但它有利于优化分布式应用程序并简化这些应用程序的编程。
在以下用例中，我们正在处理一个可组合的基础设施，特别是检查当前的异构集群。我们有各种不同的设备在这个领域特定的架构下运行。因此，将这些资源分配给服务器是一个重大挑战，正如我之前提到的。这在工作负载变化时尤其成问题。
如果这些设备被静态地附加到服务器上，那么平衡通用计算资源和领域特定架构（DSA）资源就变得非常具有挑战性。然而，如果我们有一个灵活的计算资源池，这些资源可以被重新组合以更好地适应不同的工作负载。因此，当一个工作负载到来时，我们可以分配不同的资源来使用，从而更有效地利用可用的计算资源，并减少数据移动的数量。
例如，所有设备都可以共享内存和存储，允许直接从存储媒体访问数据，而不需要从远程位置复制数据到本地位置才能进行计算。通过提供统一的高性能内存语义互连，可以实现这种效率和数据移动的减少。
让我们深入了解一些我们如何实现这一目标的细节。我们首先看一下统一总线（UB）的编程模型。
UB 的一般编程模型，我们称之为统一远程内存或 URMA，允许每个资源通过内存地址进行寻址。本质上，UB 中的内存地址有一个实体 ID，用于识别计算节点，以及一个 UASID，这是计算节点的地址基础的 ID。VA 是该地址空间的偏移量。由于这是一个完全合格的 UB 虚拟地址，远程内存可以映射到应用程序的地址空间。
这就是我们如何实现应用程序的单一地址空间。如果我们看看左下角的图，我们可以看到应用程序的线性地址基础和从这个远程内存动态映射的远程内存的段。这意味着你可以使用同样的方法来访问这些资源。
本地内存和远程内存在应用程序地址中集成，从而支持三种类型的操作。第一种操作是同步的，本质上，存储指令和原子指令到这个映射的虚拟地址就像来自应用程序软件的那些指令一样。这个操作本质上就像访问一个正常的地址，使用标准的计算机指令。
第二种类型的操作，被称为异步操作，类似于一个指向统一总线（UB）的内存复制命令，UB 将执行它。在这个事务完成后，UB 通知 CPU 内存操作已经完成。此外，UB 支持消息传递，可以被视为双向操作。它涉及到向数据发送一个消息端口，并从端口获取数据，这个过程非常直接。
UB 的另一个核心设计特性是它遵循内存顺序，因为它本质上是一个内存结构。因此，这些统一内存访问（URMA）操作以乱序方式执行，以最大化访问并行性。然而，在某些情况下，我们仍需要遵循特定的操作顺序。这就需要应用程序或程序员明确使用这些围栏指令，或将它们放入一个明确有序的队列或组中，以确保该顺序。
现在让我们来看看这些 URMA 操作如何在 UB 中实际工作。UB 完全集成到 CPU 中，包括一个关键的内存管理单元，被称为 UBMMU。例如，让我们考虑从远程地址加载数据的过程。假设，远程内存已经映射到一个本地地址基址，这个本地虚拟地址是 MVA 0。
当软件或 CPU 执行这个加载指令时，CPU 的本地内存管理将这个内存 - MVA 0 - 通过检查页表并将其转换为一个带标签的物理地址，TPA 1。这个 TPA 1 然后映射到 UB 空间。
统一总线内存管理单元（UBMMU）模块捕获数据，我们检查另一个表，远程内存区域表。这个表将地址转换为一个完全合格的 UB 内存地址。接下来，访问被转换为一个 UB 内存操作，并通过统一总线协议发送到远程节点。
在接收到操作后，远程端使用 UBMMMU 模块处理地址。然后，它检查内存区域保护表，以验证访问是否有效。如果验证通过，它会参考另一个表，UB 地址查找表。
这个表本质上是页表的可扩展缓存，类似于转换侧边缓冲器（TLB），但大小明显更大。它基于内存操作，并保留大量数据。如果 UB 地址查找表持有这个 UB 内存地址的条目，它可以直接返回物理地址。然后执行物理地址，加载数据，并将值返回给源。
在出现未命中的情况下，UBMMU 模块执行页面遍历，以定位主节点应用程序的页面表，并找到实际的物理地址。在某些情况下，如果地址不在内存中 - 例如，如果它已被主操作系统交换出去 - 它将触发对应用程序的页面错误。然后操作系统执行交换操作，一旦操作恢复，数据就会被记录并返回给用户节点。
这种与 UBMMU 的集成使其能够直接读取应用程序 CPU 的内存和页面表，这是一个独特的功能。它可以管理页面错误，不需要在主节点固定物理内存。主节点可以根据其策略自由管理物理地址，而不会干扰整个访问过程。
除了基本的 URMA 操作，统一总线也是可编程的，有一个我们称之为 Orchestrator 的编程引擎。
统一总线可以将一组统一内存访问（URMA）操作转换为一个复杂的事务，这是一个允许将多个操作一次性分组并提交给统一总线的功能，统一总线然后可以执行这些操作，而无需进一步的 CPU 中断。这使得复杂的事务可以进行，而不增加 CPU 开销，与当前的 IO 程序形成鲜明对比。
在传统的 IO 程序中，每个操作都必须由 CPU 控制，导致每个 IO 命令都会增加 CPU 的工作负载。这个过程既耗时又复杂。然而，统一总线有能力远程卸载这些操作。例如，一些操作，如远程操作，可以被压缩成一个小程序，并发送到一个远程的统一总线进行完成，从而消除了主节点和目标节点之间不断来回通信的需要。
统一总线还包括编排指令，包括可以在运行时填充详细数据值的操作参数，以及分支、循环、等待和调用指令。这允许执行条件和循环操作，以及协调其他编排操作。
UB 的编排能力的一个实际应用可以在复制事务中看到。
例如，客户端可以编排内存写入事务并将它们发送到主节点。这个主节点执行指令，写入不同的备份，并收集所有的结果。如果所有的结果都成功，主节点可以在一轮中将结果返回给客户端。
这确保了整个事务不涉及 CPU，从而实现了更快的操作和更低的延迟。
UB 遵循软件定义的设计原则。它具有一个 UB 交换机，本质上是一个为转发优化的分布式数据平面。这个极低延迟的转发引擎在简单查找后大约需要 90 纳秒就可以转发一个数据包。
UB 通过一次或两次内存查找执行快速转发操作。在此过程中，UB 控制器（一个逻辑上集中的控制平面）起着关键作用。它在服务器上运行，配置和控制所有 UB 交换机执行转发任务。
UB 堆栈是软件定义的。通常，使用七层协议。然而，在一些 UB 的使用案例中，并不需要所有这些协议。演讲者强调，在某些情况下，例如当 UB 直接与计算设备或内存模块连接时，不需要网络头和传输。事务层可以直接链接到链路层。
这是通过在每一层上使用通用协议头实现的，每个协议头都包含两个字段。第一个字段指示层的配置和类型，而第二个字段指向当前协议有效载荷中封装的协议。例如，在直接 UB 链接中，链路层协议指向事务，绕过网络和传输层。这种协议堆栈的可重新配置性增强了 UB 的适应性，使其能够在各种情况下表现相当。
UB 还包括端到端的主动拥塞控制。为了将单个芯片扩展到更大的规模，有效的拥塞控制至关重要。在大型网络中，拥塞是不可避免的，这会导致由于排队延迟而在性能上出现显著的降级。目标是避免网络带宽的利用率过低或者经历过多的延迟。
现在我们来谈谈一种我们称之为”限制性 AQM”，或者 C-AQM 的新型拥塞控制协议的设计。这个协议基于端到端的，主动的信用基础的拥塞控制原则进行操作。基本的概念是，端点和中间交换机协同工作，遵循请求和承认的模式。
当端系统希望改变速率时，交换机将效率控制器与公平性控制器分开。效率控制器的主要目的是确保链路带宽的高度利用，但不过度，目标是实现几乎零队列和零丢包。同时，公平性控制器致力于维护服务质量，并在竞争流量中实现公平。
限制性 AQM 协议的工作流程如下：当系统试图增加速率时，它发送一个请求并将其嵌入到数据包头部。当数据包头部通过每个交换机时，效率控制器根据交换机端口上的可用带宽决定是否将其分配出去。然后，公平性控制器独立操作，从高速流量中获取带宽，并将其引向低速流量。
交换机决定是否批准请求，当它到达目的地时，将该信息在数据包头部返回。然后，这些信息在确认头部中回显，当它到达源头时，根据反馈调整速率。
设计这个方案的一个重大挑战是确保协议简单，并且可以轻松地在硬件中实现，以实现零丢包，零队列和高带宽保留。
模拟已经显示，与常规的拥塞控制相比，我们的方法通过主动适应条件提供了改进的性能，常规的拥塞控制经常导致更高的队列延迟。
现有系统在扩放时可能会经历显著的延迟。然而，由于一个高效的控制器有效地避开了这种情况，延迟几乎被消除。
应该注意的是，URMA 仍然是一个非常低级的语义。为了便于编程，我们围绕 URMA 操作设计了一个统一的内存开发套件。它为程序员提供了一系列的编程 API，不仅是这些非常低级的 URMA API，还有一个可以用来编排内存事务的框架。此外，它包含高级抽象，允许轻松使用这个共享内存。
有了分布式内存操作 API，人们可以基本上在这个共享内存上管理内存，也可以分发事务性内存。这提供了构建事务性内存的固有 UB 特性，使得可以创建可以原子性更新的分布式数据结构。因此，这个共享内存可以被轻松利用。
UMDK 的目标是提供相同的 API，即使没有 UB 硬件。实际上，这个 UMDK 可以与现有的硬件一起操作，但是所有这些特性都是通过软件模拟的。这使我们确信，它正在为应用程序从当前的编程模型硬件向 UB 标记的系统过渡建立一座桥梁。
总的来说，我们提出了一种新型的网络：计算原生网络。我们相信这将是未来分布式系统的范式转变。这是一个以内存为中心的，可扩展的，高性能的统一互连，旨在连接所有的异构设备。它在 AI 计算，负责任的计算，大数据和 HPC 中有许多应用。
然而，我们在完全实现这个愿景之前，仍然面临许多挑战。其中一个挑战是将协议设计转化为高性能芯片设计，这需要一个大大简化的协议，因为硬件区域资源有限。
我们还希望在统一总线（UB）中支持缓存并发，但我们仍需要确定支持如此大规模系统所需的缓存并发类型。
在处理大规模系统时，故障是无法避免的。目前，现有操作系统中的内存故障处理效率不高。我们需要一种更优雅、更高效的方法来处理内存故障。
我们还需要付出大量的努力，转移现有的应用程序，并利用 UMDK 来优化它们的性能。
我相信我已经涵盖了今天的所有主题。谢谢，我欢迎任何反馈。
（主持人陈凯教授）谢谢你的演讲。我们现在可以接受一些问题。你可以问第一个问题。
问题 1：谢谢你的精彩演讲。我同意你的哲学和设计理念，但我有一个问题，以更好地理解你的工作。
在你的第六张幻灯片中，你比较了现有的传统处理方法，其中一个操作系统在中间处理其他设备并需要驱动程序。在下面的图表中，据我理解，像内存 MMU 或磁盘管理这样的功能并没有神奇地消失。相反，它们已经以不同的形式被重新定位到其他地方。例如，你可能已经将操作系统功能的一个子集移动到网络接口卡（NIC）或系统芯片（SOC）中，或者你可能有一个专用的芯片来处理这个问题。
你还需要某种硬件适配层来提供驱动程序以前提供的功能。在你后面的幻灯片中，你提到了一些全局自动化来处理，例如，地址冲突。当你插入更多的内存或磁盘，或添加新设备时，可能会有一些挑战。一些设备甚至可能离开网络。
我不确定我的理解是否正确，或者你是否有不同的解决这些问题的方法。
答案 1：这个图旨在说明从数据路径中获得的好处。当然，你仍然需要一个管理平面来管理，例如，存储块上的元数据查找和资源分配。我们仍然需要在某个地方，也许是在操作系统中，进行这种工作。
这只是为了说明数据路径访问的开销。这意味着一旦你有了这个块并且你想在上面写数据。那么我们为什么还需要像 VBS 这样的系统呢？这是因为当前系统中缺乏虚拟地址，无论是网络，RoCE，还是 IO。在这些系统中，你需要操作系统在中间来确保安全和分离。
然而，统一总线（UB）是不同的。它天生就支持虚拟地址和不同的虚拟地址空间。硬件利用 UB 内存管理单元（UBMMU）进行隔离。这允许资源直接暴露给应用程序。因此，应用程序写入就像它正在写入内存一样。
这就是从数据路径中获得的好处的基本原理。
问题 1：谢谢。所以，当在不同的地方添加这样的层时，人们可能会想知道它们与以前的设计相比如何，或者他们潜在优越性背后的理由是什么。好处源于我们现在有一个虚拟层来解决虚拟系统。
答案 1：这不在软件中；虚拟地址主要由硬件处理。地址在硬件中被翻译。
问题 1：所以我们需要一些全局知识来解决地址冲突吗？
答案 1：使用 UB 端点（UBEP）解决地址冲突很容易。UB 地址有三个元组。每个节点 ID 本质上都标识了位于计算设备或计算节点上的资源。它有一个可以被视为应用程序 ID 的地址空间，或者可以被理解为资源自然地被不同的虚拟空间划分。
通过使用这个，你可以获得足够的数据路径知识。当然，我们仍然有控制平面和管理平面来分配这个地址空间并确定资源位于哪里，即在哪个计算节点。我们仍然在软件中有这个逻辑，但我们相信管理计划的访问频率比数据平面低。
问题 2：我确实有两个问题：一个有点技术性，另一个有点抽象。我很好奇这是否应该被称为”网络原生计算”。然而，抛开这个不谈，我对你的拥塞控制机制特别感兴趣。
在过去，我在开始 ATM 工作时探索了基于信用的拥塞控制。随后，我们面临两个关于这种基于信用的控制的选择。一个是采用 ECN 的想法，这与你的方法相呼应，你的方法是从远端携带信息并保持信用以确保零损失和最小排队。
然而，人们最终选择了逐跳解决方案，而不是端到端的解决方案，主要是因为处理缓冲变化的挑战很大。如果你选择端到端，你有可能过度扩展缓冡。你有考虑过这个问题吗？
我更喜欢这个系统能够运行，而不是最后选择的基于信用的逐跳控制。这种方法将我的 ECN 想法与信用结合起来，但它确实带来了挑战。我很好奇你是否考虑过这个问题。
回答 2：我正在试图理解你对交换系统内缓冲管理的担忧。我理解的你的主要关注点是，例如，我们如何管理启动过程。当一个流开始时，我们在没有任何系统状态知识的情况下发送一串数据包。
问题 2：即使在最小的变化中，也需要一些缓冲，对吗？
回答 2：这个提议与 ECN 的想法略有不同。它建议你不仅在出现拥塞和需要备份时得到通知，而且当我希望采取额外的缓冲措施时，通过红色和铅来确认与交换机的对齐，你也会得到通知。
该概念类似于使用软件在头部放置请求。如果网络交换机内部识别到这些请求，它们需要在下一轮中得到处理。否则，这些请求将丢失并需要重新发出。通过遵守这个协议，我们至少确保在数据传输发生之前，缓冲区已经存在于中间交换机中。
问题 2：我同意，如果有一种方法可以截断这个循环，处理可能会用更少的缓冲量发生。
回答 2：的确，当决策变化发生时加快过程是一个明智的建议。可以直接从交换机向源发送反馈，而不是将其路由到末端并返回。我们考虑过这种设计，但其复杂性一直是一个威慑因素。我们可能会在以后探索这个选项，但现在，我们利用的是端到端的事务方法。
当前的事务程序包括发送请求、接收响应和执行响应。这是我们目前使用的三方认证。
问题 3：考虑到复杂性和成本，我有一个更广泛的问题。在 80 年代初，人们努力创建一个类似于这个的框架。目标是有一个单一的通用连接器或集群用于存储和网络。我们在满足每个人的需求的同时，难以找到一个合理的成本点。
重新审视这个问题，我想知道你是否考虑过这些问题，可能对为什么这可能从根本上改变有所了解。为什么现在做这个有意义？
回答 3：这确实是一个好问题。当我们开始时，我们面临许多挑战。然而，我认为有两件事值得考虑。
首先，我认为我们处理的计算设备类型正在变得越来越少。当我们检查我们的集群时，我们发现以前我们有各种类型的设备，包括存储、内存、计算 XPU 和各种类型的 I/O 设备，所有这些设备都以较慢的速度运行。现在，当我们观察这个中心，所有的设备都在发展，剩下的只有内存和计算设备。甚至存储已经转变为内存。因此，计算机变得更加多样化。我们有通用计算 CPU、GPU、NPU、DPU 和各种类型的 DSA。然而，所有这些计算设备都类似于处理器，并且有内存。
这个变化意味着我们创建的不同语义已经转化为内存语义。这引导我们到了一个想法，我们需要改变主要的语义与网络，将其转化为内存语义而不是字节流抽象。这构成了我们动机的重要部分。我们需要将所有类型的设备作为计算设备，这些 XPU，使用内存协议进行互联。所以，内存协议可能会成为主流，而不是流。
问题 4：我明白你对我们在这个统一总线（UB）设计中使用的底层通信协议感到好奇。我们还在使用以太网、IP，还是我们开发了一个新的？
答案 4：的确，我们开发了一个新的协议。正如我之前提到的，我们正在寻求非常高的速度，试图将其提升到每通道约 800 吉比特每秒。
这个新协议在网络层工作，类似于 IP 网络，但我们使用的是不同类型的头部。这些头部可以嵌入拥塞信息和多路径信息，从而支持多路径路由。
我们从现有的 IP 网络中借鉴了一些设计思路，但并非所有特性都对齐。最重要的区别是我们采用了整个 SDN 方法，而不是路由，因为我们主要关注的是集群数据中心类型的网络。
问题 4：所以，这意味着你们开发了一个新的通信协议来替代以太网和替代 PCIe，对吗？
答案 4：是的。
的确，我们仍然可以操作 IP。本质上，人们可以继续在统一总线（UB）上使用 IP。
（主持人陈凯教授）有没有人有问题？如果没有，让我们对这个富有洞察力的演讲表示感谢。谢谢。
（完）