百度高级项目高峰：低时延网络实践

大家下午好，非常高兴能有机会这里跟大家分享，我来自百度系统部，今天分享的主题是百度低时延网络的实践，主要包括三个部分，第一是低时延网络解决方案，会介绍百度在低时延网络解决方案设计过程中如何思考的，第二是低时延网络技术展望，会介绍低时延网络技术研究方向，第三是总结。

首先说一下业务背景，人工智能、高性能计算云，实时大数据的分析，这些业务都属于时延敏感型业务，为什么说是时延敏感业务，这里面要介绍几个技术场景，如深度学习、分布式计算、分布式存储、计算存储分离，这些技术对数据中心网络提出了明确的要求，无丢包和低时延。网络丢包对业务性能的影响非常严重，网络的时延也是影响集群计算性能的首要指标。面对这些需求和挑战，我们的数据中心网络也要同步做出相应的改变，来适应技术发展需要。以前我们数据中心是追求大带宽，无阻塞，到今天应该追求低时延、无丢包。我们的数据中心网络架构设计，要从以带宽为中心的设计切换到以时延为中心的设计，降低时延的波动范围。

设计低时延网络，先要分析一下网络时延组成，有五个部分，光电传输时延、数据串行时延、设备转发时延、重新排队时延、主机处理时延。光点传播时延是固定值，没办法改变，数据串行时延和设备转发时延，主要是取决于芯片技术的发展，其中信号传输和芯片pipeline转发时延是固化的，依靠升级硬件降低时延的效果非常有限，我们聚焦的重点是重新排队时延和主机处理时延，通过主机端加速技术，可以减小主机处理时延，我们选择的方向是RDMA和RoCE，主要考虑成本和技术成熟度，另外随着100G技术的成熟，RoCE的优势越来越明显，网络侧我们选择的方向是DCB和ECN，通过流控技术，避免网络拥塞造成的业务丢包。

主机端的加速，我们是RDMA和RoCE，RDMA性能方面有两个方面，RDMA的性能优势主要体现在以下几个方面。1.Zerocopy：减少数据拷贝次数，由于没有将数据拷贝到内核态，传输延迟会显著提高，2、Kernelbypass&Protocoloffload：不需要内核参与，数据通路中没有繁琐的处理报头逻辑，不仅会使延迟降低，而且也大大节省了CPU的资源。

RDMA和TCP相比，性能提升比较明显，但是数据包大小，以及业务模型不同情况下，提升的效果也不同。我们在语音识别训练提速2倍，在机器翻译训练提速15倍。

RoCE是RDMA承载协议，RoCE和Infiniband的性能基本相近，而且比iWARP产业生态更加健全，主流网卡厂商都已支持。除此之外，RoCE网络在数据链路层支持标准以太网协议，在网络层上支持IP协议，因此可以无缝融合到现有的数据中心网络中，部署和运维更加方便，而且设备成本更低。

以太网采用的是尽力而为的转发方式，每个网络设备都会尽力的把数据转发给下游的设备。当下游设备处理能力不足的时候，网络就会出现拥塞或者丢包，所以网络本身是不可靠的，无论是TCP或者RDMA协议，网络拥塞和丢包重传都会让业务性能受到影响，尤其是RDMA协议对网络丢包的容忍度更低。如何减少或者避免网络拥塞和丢包，现在通用的解决方案是PFC和ECN的流控技术，PFC是一种基于队列的反压协议，在单机场景下，PFC可以快速、有效的调节服务器速率来保证网络不丢包，但是在多级网络中，就会出现不公平降速、PFC风暴、死锁等问题，而且当有异常服务器向网络中注入PFC报文时，还可能造成整个网络瘫痪，因此，在数据中心开启PFC，需要通过对Pause帧进行严格的监控、管理，以保证网络的可靠性。ECN是一种基于流的端到端流控技术，效果上会优于PFC，但是也不是很理想，主要有几个问题，1、ECN缺点是需要网卡侧生成反压报文，反馈路径周期比较长，2、随机性标记，会不公平。3、水线设计比较复杂，这也是现阶段ECN方案的最大挑战，因为水线不是一个固定值，要结合网络架构和业务特点来设计。4、目前各个网卡厂商拥塞算法不一致。虽然方案不理想，但是目前也没有更好的选择。

从解决方案设计上面来说，ECN和PFC组合配置，针对PFC固有的缺陷问题，可以通过优先触发ECN报文，用来减少网络中PFC的数量，在PFC生效前完成流量的降速。

依靠有效流控机制只能是减少网络拥塞和丢包的发生，网络是共享资源，面对多个业务并发流量导致拥塞的问题，是很难避免的。高效的网络一定是避免触发流控机制，那么在组网架构方面也要同步思考这个问题，比较有效的办法是用带宽来换时间，为服务器提供端到端的线速转发能力。下面介绍一下网络架构设计过程中要关注什么，在低时延网络架构设计中最关键的指标是加速比，加速比越大，网络拥塞越少，时延越低。目前我们的网络架构设计是1：1加速比，下一代新架构会提升加速比到4：3以上，主要来避免fabric内部拥塞和丢包问题，加速比提升会让网络性能提升，新架构在性能提升的同时，也要付出更高的组网成本。

下面分享一下在整个设计过程中的思考。在整个低时延网络解决方案中有两个选择，第一个是单独部署PFC，第二个就是PFC和ECN的结合。结果很明显，ECN+PFC的方式优于单独部署PFC.加速比是很关键的指标，决定了我们的效率，加速比越高，网络优势就越明显。第三点就是水线的设计，PFC的水线越大，ECN的水线要适合网络模型。

下面分享一下我们在方案设计过程中的一些分析，有两种技术方案选择，第一种是单独部署PFC、第二种是PFC+ECN组合，我们分别在加速比1：1和加速比4：3环境下，以及在不同的带宽利用率下面测试，分别是50%、75%、100%利用率，结果很明显，ECN+PFC优于单独部署PFC，而且在各种利用率情况下均有优势。加速比是关键指标，加速比决定网络效率，越高，优势越明显。水线设计一定要合理，PFC水线的设置只要满足HEADROOM，越大越好，ECN水线的设置需要视不同流量模型而定。

这个分享是PFC+ECN和新方案的对比，新方案是我们在探索的一个方向，就是在tor下行端口单独部署ECN，这个方案需要两个前提条件，ECN控制环不失效，fabirc内部不能丢包，提高加速比来解决fabric内部丢包问题，从结果上看会优于PFC+ECN的方案，但是如果fabric内部无法保证不丢包，在仅部署ECN时，丢包率非常高，100%利用率时，丢包率高达5%以上，影响会非常严重，稳妥一些还是PFC+ECN的组合方案比较好。提高加速比可以缓解Fabric内部端口的拥塞，仍然存在流量不均导致丢包的可能，也要配合一种理想的负载均衡方案。

以上是百度在低时延网络解决方案上面的思考，下面是我们对未来的技术展望。我们希望从四个方面进行深度的优化，控制面、数据面、管理面、功能强化。

控制面-优化反馈机制，目前拥塞反馈信息比较单一，反馈内容很少，由于是网卡做拥塞通知，反馈路径周期太长，控制面数据未高优保障。需要优化通知消息，引入更多级别的拥塞通知机制，包括拥塞程度等信息，通过多种方式提速，比如交换机设备直接反馈拥塞通知，缩短反馈路径，确保控制面消息在网络传递过程中不被丢弃，同时由交换机来触发丢包重传。

数据面-多路径负载均衡，当前多路径下多采用基于流的哈希算法，实现数据在不同链路上调度，大象流叠加容易造成流量不均，在特定路径的拥塞。如前面解决方案中介绍，fabric内部的负载均衡很重要，需要从负载均衡算法方面进行优化，例如：基于成员接口历史负载情况，选择空闲链路。把出接口队列长度作为流量均衡的hash因子。切割大象流，把一条流切分为多组，调度到不同路径，且保证不乱序。从这三个方面协作处理，实现完美的负载均衡调度

管理面-自适应网络。低时延网络对运维的管理自动化提出更多的要求，相对于低时延网络在丢包、性能方面提出更高的要求，网络运维管理要屏蔽网络环境变化对性能的影响，确保配置永远是最优的。要达到自适应的网络效果，我们认为应该建立分析。第一点是业务的探索和发现，我们要构建自己业务测量的能力，把业务沿途网络节点转发信息进行记录和提取，第二点是计算和特征分析，根据现网实时数据和业务特征，计算出最优的水线阈值和最优策略。第三点是下发和持续的优化。根据业务流量特点，自动配置并动态调整参数，自动下发给服务器和网络设备，实现自适应网络配置。

第四点是功能强化-队列优化，数据中心内流量特征有两种，大象流和老鼠流，大象流对时延不敏感，丢包对整体性能影响较小，但是占据了80%的流量，网络拥塞期间，很容易把交换机的队列占满，时延敏感的业务流量被饿死，需要从交换机队列层面优化，将大象流隔离到单独的队列中，为老鼠流预留足够的buffer，以及单独的队列设计，实现设备层面的低时延转发。

以上技术分享就结束了。在低时延网络里面业界也关注很多，也有很多相应的技术，由于时间关系就分享这么多。总结一下今天我的分享。共4个部分，第一部分是业务定位，低时延网络在百度来说主要是面向百度云和人工智能的内生需求，我们分别部署了25G、40G、100G的低时延网络，用来支撑业务需求。从网络定位上面，我们配合整体的网络布局，实现局部的加速的能力。第三点是产品定位，目前低时延网络中仍然有很多问题和挑战，技术的优化空间还很大，在未来也希望跟厂商共同的去探索。第四点是架构演进定位，向大规模网络架构探索，随着技术发展，逐步优化迭代。