针对RoCEv2网络的高性能拥塞控制（HPCC++）技术
时间：2022年10月18日
介绍
今天我们将探讨高性能拥塞控制（HPCC）机制，以及如何利用带内流分析器（IFA，In-band Flow Analyzer）来实现它。我们还将分享一个具体的部署案例。
Broadcom正在芯片到芯片遥测领域进行创新，这是我们关注的重点之一。除了在我们的芯片上进行创新外，我们还通过遥测和监控规范向PSI社区贡献规范和功能。该规范包含流遥测、丢弃后镜像、流追踪器和带内遥测等多个遥测特性，其中带内遥测是一个核心机制。
带内遥测
带内遥测（In-band Telemetry），或者我们称之为带内流分析器（IFA），与SNMP流追踪器等带外遥测机制有所不同。带外方法依赖于通过操作系统周期性地检索芯片维护的计数器。而带内遥测则直接在用户数据包的数据平面中添加数据包处理元数据，无需依赖主机CPU，实现了数据包级别的可扩展性，且不影响整体CPU性能。
当数据包在网络中从一个节点跳转到另一个节点时，每个节点都会以累积的方式添加自己的元数据。这些元数据包括交换机ID、到达和离开时间、到达和离开端口、队列ID和拥塞状态等详细信息。这些详细信息被直接添加到用户数据包中，并随着数据包在网络中传输。
数据包经过的每个节点都会累积元数据，最终在网络中的最后一个节点，这些元数据会被收集并发送给收集器。这种方法提供了关于数据包行为的深入洞察，同时不会给主机CPU带来过多负担，是网络遥测中一种高效且可扩展的解决方案。
应用案例
IFA有多个应用案例，我们还在不断探索中。其中一个与条件监测和RoCEv2网络优化紧密相关。另一个重要的应用案例是延迟监测，这对于每天需要处理应用延迟的网络运营商来说至关重要。IFA在这一领域提供了前所未有的可见性。
此外，IFA还支持网络性能监测和异常检测。实际上，我们今天下午还将与阿里巴巴联合举办一个关于网络性能异常检测的专题会议，大家如果有兴趣，欢迎参加以了解更多相关应用案例。
IFA同时支持实时流量（live traffic）和探测流量（probe traffic）。
HPCC简介
如今，RoCEv2已广泛应用于AI等领域，这些领域对无损网络有很高的要求。RoCEv2依赖于PFC（Priority-based Flow Control）和ECN（Explicit Congestion Notification）两种机制。其中，ECN在发生拥塞时标记数据包，而PFC则充当“保护伞”，确保数据包不会丢失。DCQCN（Data-center Quantized Congestion Notification）就是其中一种利用ECN标记来维护无损网络的拥塞控制协议。
DCQCN机制
实际上，我们观察到的一个现象是，源端往往倾向于发送大量流量，因为它们对路径状况一无所知。由于缺乏精细的调整信息，缓冲区很容易就被填满。在之前的演讲中，我们已经强调过这一点，并展示了现有机制如何将大量数据包推送到缓冲区中。这种过载状态会导致响应时间延长。
如果转向基于网络遥测和拥塞控制的机制，我们将有更多信息来实现精确的拥塞通知。这样，我们可以在更小的缓冲区和更快的响应时间内实现更平稳的网络运行。
HPCC机制
我来谈谈拥塞控制在高速网络中的重要性。对于大数据传输（large transfers），应用程序通常需要高吞吐量；而对于小消息传输（small messages），则需要低延迟。此外，应用程序绝不允许数据包丢失，因为数据包丢失可能引发PFC风暴和TCP数据丢失，从而导致网络稳定性问题。
为了同时满足这三个目标，我们提出了HPCC（High Precision Congestion Control）。传统的拥塞控制主要依赖于启发式算法，这些算法基于数据包丢失、经验性延迟和ECN来识别网络状况。然而，这些算法通常需要较长时间才能收敛，并且它们依赖于网络中已经检测到的拥塞，这意味着损害已经发生。
由于我们使用了多种启发式算法，因此通常需要调整大量参数以确保网络正常运行。然而，当我们在数据中心内部署带内遥测用于监测和诊断时，我们意识到可以将带内遥测技术应用于拥塞控制。因为一旦我们掌握了这些实时信息，就可以精确地检测网络中的链路利用率。这样，我们就不必再依赖启发式算法来猜测网络状况，而是可以准确地了解网络中的实际利用率。
如果R-NIC有更多的可用带宽，我们可以增加带宽，并且如果出现拥塞，我们可以降低发送速率。此外，我们还可以使用接近链路最大带宽的所有可配置带宽，但尚未完全达到，因此我们可以实现接近100%的带宽利用率，但又略低于100%。在流量突发时，我们有一定的带宽冗余。我们可以利用带宽冗余来吸收流量突发。这样，我们既可以实现高吞吐量，也可以实现接近零的网络排队延迟。
为了更具体地说明HPCC的优势，我们将其部署到了机器学习应用程序和存储应用中。以存储应用程序为例，我们将其部署到了云中的存储集群。在典型的云集群中，计算和存储通常是分离的。当虚拟机需要访问其存储时，它们会生成存储IO，这些IO流量会通过网络传输到存储集群。因此，带宽和延迟对于此类应用至关重要。根据我们的研究测量，存储流量实际上占据了数据中心总流量的60%以上。
存储流量需要低延迟，同时存储流量通常会被分散到所有存储节点上以实现高并行性。这意味着存储流量不仅占据了大量带宽，对延迟也非常敏感。HPCC的高精度拥塞控制功能能够确保存储流量在保持高吞吐量的同时，实现低延迟传输。
检测拥塞
为了检测网络拥塞，我们允许发送方（在我们的场景中为RDMA）在每次往返时间内发送探测数据包（probing packet）。这些探测数据包与真实数据包的配对具有相同的五元组信息，并通过相同的路径传输。探测数据包会经过沿途的交换机，每个交换机都会为探测数据包分配元数据。这些元数据包含了队列长度、时间戳和TX字节数等信息，其中TX字节数表示到目前为止在该队列中排队的字节数。
通过收集这些数据，我们可以推算出该链路的利用率。当探测数据包到达接收方后，接收方会生成响应数据包并返回给发送方。根据这些链路利用率信息，发送方可以判断是否需要增加或减少发送速率，以应对网络拥塞的情况。
HPCC实现
2019年，我们提出了HPCC技术，并在同年于SIGCOMM发表了相关学术论文（<HPCC: High Precision Congestion Control>）。三年后，我们与供应商展开合作，将这一想法应用到了他们的设备中，特别是支持INT（In-Network Telemetry，网络内遥测）的Broadcom芯片，以此来支持我们网络中的INT技术。
截至目前，我们已经部署了超过10万台服务器，并计划将其推广到更多的集群中。根据我们的部署经验，HPCC能够支持运行机器学习、存储和数据库应用程序的应用场景。通过实验研究，我们发现部署HPCC后，RDMA流量的尾延迟降低了80%，并且基本上消除了由缓冲区或拥塞触发的数据包丢失问题。无论是否启用PFC，HPCC都能确保数据包传输的稳定性和可靠性。
在未来，我们计划探索如何更好地利用INT技术。例如，我们可以使用INT来实时监测链路的利用率。当某条链路发生拥塞时，我们可以降低发送速率；但如果这条链路或路径超载了，我们可以考虑切换到另一条可能具有更好带宽和更低延迟的路径。我们正在研究如何利用INT技术在不同路径之间检测利用率，以便让数据流能够迁移到性能更优的路径上。这种技术对于存储流量来说尤为重要，因为存储流量通常是分散的。当读取和写入不同的存储块时，我们可以将这些存储块划分为多个小数据块，并通过平衡的网络进行传输。
然而，对于机器学习应用来说，工作负载则完全不同。由于机器学习应用需要执行全规约（All-Reduce）并从存储中复制大量文件，网络负载往往是不平衡的。在这种情况下，仅依靠拥塞控制技术可能不足以满足需求。我们需要一种方法来充分利用网络中的带宽资源，而不仅仅是单一路径。这是我们未来想要探索的方向之一，同时也是利用INT技术的重要应用之一。
结论
总之，我们鼓励大家加入我们的行列，共同探索高精度拥塞控制技术的更多可能性。我们还参与制定了IETF标准HPCC++，并在其中探讨了我们的协议、与不同供应商的合作方式以及如何保持协议、算法和格式的一致性。我们期待与大家携手合作，共同推动网络性能的优化和提升。
关于IFA部署HPCC++应用场景的描述非常精彩。对于AI/ML工作负载来说，其具有独特的特性。业界已经提出了多种机制来应对这些挑战，其中包括实现完美的负载均衡和使用带内遥测技术来识别拥塞点并从端到端的角度进行控制。
今天主要是基于带内遥测技术的示例，大家可以看到它是如何在实际应用中发挥作用的。其美妙之处在于它适用于现有的网络基础设施。只需利用遥测数据进行优化即可获得更高的性能。
-----
观众：当发送探测数据包时，每个节点（或称为跳数）都会向数据包添加一些元数据。请问每个节点添加的元数据大小是多少？另外，HPCC能支持的最长路径是多少？
关于元数据的大小，有一个定义的最小元数据集，大小从2字节开始，最大64字节。在HPCC中，我们发布了几个相关的草案，包括P4 INT、IOM和针对IFA的格式。你可以在这些草案中看到更详细的描述。
我们已部署的元数据大小为32字节。
观众：您提到使用传统的ECN和DCQCN需要较长时间才能意识到拥塞，那么与这些方法相比，HPCC能多快地检测到拥塞呢？
传统的ECN方法，只能判断是否需要减半或增加发送速率，这种方式是逐步进行的。然而，通过使用INT技术，由于能够精确掌握链路的利用率，比如70%或20%，HPCC可以直接将利用率调整至目标值，如95%。在这种情况下，我们仅需一个往返时间便能迅速将利用率调整至目标值。
观众：我理解了，这确实很吸引人。
想象一下，使用传统的ECN，每次只能获取一点信息，所以调整起来比较受限。但使用INT，可以在一个往返时间内立即调整到任何可用的链路带宽。
观众：但是，这也要求网络中的每台服务器都支持这种模式。如果有一个不支持的服务器，那么整个系统会不会受到影响？
部分是的。因为HPCC部署在RDMA上，每台服务器都使用相同的协议。但是，在交换机层面，如果交换机的一部分支持INT，但其余部分不支持，那么不支持的部分将退回到传统的拥塞控制机制，如ECN、丢包或延迟等。但如果在支持INT的交换机中感受到拥塞，HPCC的性能会优于ECN。我们的理念是，为良好的用户提供更多空间，让好的流量能够充分利用带宽。
我们的经验是，主要的转换发生在叶子交换机，也就是最后一跳。我们确保叶子交换机支持INT，以便我们能够覆盖可能发生的90%的拥塞。对于网络中的其它部分，如果不支持INT，它们将退回到ECN机制。这就是我们的策略。
观众：这些并非普通的数据包，而是专用的探测数据包。那么，这是否会增加网络流量，并因此带来额外的开销呢？你们是否考虑过在数据包中直接嵌入INT信息的方式？与单独发送探测数据包相比，这样做是否能更及时地提供拥塞信号？
其实，时间成本不是问题，因为我们仅在需要发送数据包时才会发送探测数据包。它们与数据包同步或连续发送。如果当前没有数据包需要发送，就不会发送探测数据包，因为其主要目的是复制数据包的状态。在开销方面，我们也考虑到了这一点，因为探测数据包本身非常小。这是第一点。另外，只有在需要发送数据包时，我们才会发送探测数据包。例如，在第一次往返时间中，如果有一个探测数据包和一个数据包要发送，我们就会同时发送。但在第二次往返时间中，如果没有数据包需要发送，那么我们就不会发送探测数据包。
观众：既然同时发送它们，为什么不将遥测信息放在数据包中？
原因有几个。首先是隐私和安全性问题。如果数据包中的遥测信息出现错误，我们可能会不小心丢弃客户的数据包，这对云服务商来说是非常危险的。另外，将遥测信息添加到数据包中可能会超出MTU（最大传输单元）的限制，这会导致数据包在网络中丢失。
我还想强调的是，实际上这种探测数据包在网络流量中所占的比例非常小，远远不到百分之一。这主要是因为它们每往返时间只发送一次，而且本身数据包就很小。与此相比，我们平时发送的数据包平均大小要大得多。
观众：能否分享一下发送方和接收方之间采用的间隔时间吗？您提到了它们之间的常规间隔，我想知道这个间隔的频率。
对于探测数据包，它每个往返时间一次。实际上，这取决于网络的往返时间。如果只有一个共享对，往返时间可能是10微秒。但如果1000或10000个并发共享对，并且每个共享对都会获得一个窗口来发送数据包，在这种情况下，可能需要等待很长时间才能发送探测数据包，直到数据包被发送出去。
观众：能否解释一下系统的稳定性？在面对爆发式流量和带宽波动时，是否会最终选择在服务器之间进行同步操作？如果我理解无误的话，你们似乎是通过发送探测数据包来监测网络的拥塞状态。基于这些信息，会调整特定服务器的发送速率。也就是说，类似于探测数据包，可能同时有多个服务器在发送流量。它们可能各自独立地探测网络拥塞情况。当它们增加流量并可能引发拥塞时，它们会进行测量并适当降低发送速率。这样，可能会面临一种振荡状态，即流量突然增加然后减少，如此反复。这是分布式控制的一个常见问题。你们是如何处理这一挑战的呢？
拥塞控制主要分为主模式拥塞控制（primary congestion control）和双模式拥塞控制（Dual-mode congestion control）。在双模式拥塞控制中，交换机负责决定所有主机的发送速率。然而，这种方式存在振荡问题，因为交换机作为单点，若存在不同的波动，会导致频繁的闪烁。而HPCC虽然利用了交换机的信息，但其核心是基于发送方的。它采用主模式拥塞控制算法，每个发送方可能在不同的时间点了解到拥塞状态，并随机在不同时间发送探测数据包。当某个发送方增加发送量时，其增加的时间也可能不同，因此这种增加实际上是随机化并在往返时间内分散进行的。我们的理论或分析显示，主模式拥塞控制在稳定性方面的表现优于双模式拥塞控制。这就是我们采用的方法。
观众：“双模式”具体是指什么呢？能解释一下这个概念吗？
双模式拥塞控制是一种允许交换机为网络流量决定发送速率的机制，就像RCP那样。我们稍微研究了一下双模式拥塞控制，发现它需要更长的时间才能达到稳定状态。我们无法提供精确的数值，只能给出一个大致的估计。这个估计过程需要相当长的时间。
观众：在交换机上可能会出现一些细微的波动，那么你们是基于多次测量结果还是单次测量来做出决策的呢？例如，当发送探测数据包时，由于链路上其它流量的微小突发，可能会遇到短暂的拥塞并需要迅速做出反应。是根据发送的单次测量结果来设置发送方的速率，还是基于多个测量结果来调整发送速率呢？
我们更多地是从发送方的角度，并且根据一次往返时间来进行相应的调整。我们不能超出这个一次往返时间的限制，否则会导致稳定性问题。至少，发送方需要在每次往返时间变动时，相应地调整一次发送速率。我们可以证明，这样做能够确保系统的稳定性。
--【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/单位/关注领域）