一、数据中心诉求变化
以前数据中心：
追求大带宽，无阻塞 。
现在数据中心：
追求低时延、无丢包。
二、网络时延组成
网络时延组成5部分：光电传输时延、数据串行时延、设备转发时延、重新排队时延、主机处理时延。
光电传播时延：是固定值，没办法改变
数据串行时延和设备转发时延：主要是取决于芯片技术的发展
三、降低时延工作重点
我们聚焦的重点：
我们聚焦的重点是重新排队时延和主机处理时延，通过主机端加速技术，可以减小主机处理时延，我们选择的方向是RDMA和RoCE，主要考虑成本和技术成熟度，另外随着100G技术的成熟，RoCE的优势越来越明显，网络侧我们选择的方向是DCB和ECN，通过流控技术，避免网络拥塞造成的业务丢包。
1、主机端的加速
主机端的加速，我们是RDMA和RoCE，RDMA性能方面有两个方面，RDMA的性能优势主要体现在以下几个方面：
1.Zerocopy：减少数据拷贝次数，由于没有将数据拷贝到内核态，传输延迟会显著提高，
2、Kernelbypass&Protocoloffload：不需要内核参与，数据通路中没有繁琐的处理报头逻辑，不仅会使延迟降低，而且也大大节省了CPU的资源。
RDMA和TCP相比，性能提升比较明显，但是数据包大小，以及业务模型不同情况下，提升的效果也不同。我们在语音识别训练提速2倍，在机器翻译训练提速15倍。
RoCE是RDMA承载协议，RoCE和Infiniband的性能基本相近，而且比iWARP产业生态更加健全，主流网卡厂商都已支持。除此之外，RoCE网络在数据链路层支持标准以太网协议，在网络层上支持IP协议，因此可以无缝融合到现有的数据中心网络中，部署和运维更加方便，而且设备成本更低。
2、网络侧流控技术
以太网为何容易丢包
以太网采用的是尽力而为的转发方式，每个网络设备都会尽力的把数据转发给下游的设备。当下游设备处理能力不足的时候，网络就会出现拥塞或者丢包，所以网络本身是不可靠的，无论是TCP或者RDMA协议，网络拥塞和丢包重传都会让业务性能受到影响，尤其是RDMA协议对网络丢包的容忍度更低。如何减少或者避免网络拥塞和丢包，现在通用的解决方案是PFC和ECN的流控技术。
PFC 和 ECN
PFC
PFC是一种基于队列的反压协议，在单机场景下，PFC可以快速、有效的调节服务器速率来保证网络不丢包，但是在多级网络中，就会出现不公平降速、PFC风暴、死锁等问题，而且当有异常服务器向网络中注入PFC报文时，还可能造成整个网络瘫痪，因此，在数据中心开启PFC，需要通过对Pause帧进行严格的监控、管理，以保证网络的可靠性。
ECN
ECN是一种基于流的端到端流控技术，效果上会优于PFC，但是也不是很理想，主要有几个问题：
1、ECN缺点是需要网卡侧生成反压报文，反馈路径周期比较长。
2、随机性标记，会不公平。
3、水线设计比较复杂，这也是现阶段ECN方案的最大挑战，因为水线不是一个固定值，要结合网络架构和业务特点来设计。
4、目前各个网卡厂商拥塞算法不一致。虽然方案不理想，但是目前也没有更好的选择。
从解决方案设计上面来说，ECN和PFC组合配置，针对PFC固有的缺陷问题，可以通过优先触发ECN报文，用来减少网络中PFC的数量，在PFC生效前完成流量的降速。
避免触发流控机制+加速比（网络架构设计过程中要关注什么）
（PFC流控，但是拥塞发生后触发的。那要在拥塞之前就接入，避免发生拥塞：ECN）
依靠有效流控机制只能是减少网络拥塞和丢包的发生，网络是共享资源，面对多个业务并发流量导致拥塞的问题，是很难避免的。高效的网络一定是避免触发流控机制，那么在组网架构方面也要同步思考这个问题，比较有效的办法是用带宽来换时间，为服务器提供端到端的线速转发能力。下面介绍一下网络架构设计过程中要关注什么。
1、加速比
在低时延网络架构设计中最关键的指标是加速比，加速比越大，网络拥塞越少，时延越低。目前我们的网络架构设计是1：1加速比，下一代新架构会提升加速比到4：3以上，主要来避免fabric内部拥塞和丢包问题，加速比提升会让网络性能提升，新架构在性能提升的同时，也要付出更高的组网成本。
低时延网络解决方案
下面分享一下我们在方案设计过程中的一些分析，有两种技术方案选择，
第一种是单独部署PFC
第二种是PFC+ECN组合
我们分别在加速比1：1和加速比4：3环境下，以及在不同的带宽利用率下面测试，分别是50%、75%、100%利用率。
评估项目：
1.仅PFC和ECN+PFC
2.在不同的网络利用率和加速比下。
结果很明显：
1、ECN+PFC优于单独部署PFC，而且在各种利用率情况下均有优势。
2、加速比是关键指标，加速比决定网络效率，越高，优势越明显。
3、水线设计一定要合理，PFC水线的设置只要满足HEADROOM，越大越好，ECN水线的设置需要视不同流量模型而定。
PFC+ECN VS 新方案
这个分享是PFC+ECN和新方案的对比，新方案是我们在探索的一个方向，就是在tor下行端口单独部署ECN，这个方案需要两个前提条件，ECN控制环不失效，fabirc内部不能丢包，提高加速比来解决fabric内部丢包问题，从结果上看会优于PFC+ECN的方案，但是如果fabric内部无法保证不丢包，在仅部署ECN时，丢包率非常高，100%利用率时，丢包率高达5%以上，影响会非常严重，稳妥一些还是PFC+ECN的组合方案比较好。提高加速比可以缓解Fabric内部端口的拥塞，仍然存在流量不均导致丢包的可能，也要配合一种理想的负载均衡方案。
四、对未来的技术展望
以上是百度在低时延网络解决方案上面的思考，下面是我们对未来的技术展望。我们
1、四个方面进行深度的优化
希望从四个方面进行深度的优化，控制面、数据面、管理面、功能强化。
控制面-优化反馈机制，目前拥塞反馈信息比较单一，反馈内容很少，由于是网卡做拥塞通知，反馈路径周期太长，控制面数据未高优保障。需要优化通知消息，引入更多级别的拥塞通知机制，包括拥塞程度等信息，通过多种方式提速，比如交换机设备直接反馈拥塞通知，缩短反馈路径，确保控制面消息在网络传递过程中不被丢弃，同时由交换机来触发丢包重传。
数据面-多路径负载均衡，当前多路径下多采用基于流的哈希算法，实现数据在不同链路上调度，大象流叠加容易造成流量不均，在特定路径的拥塞。如前面解决方案中介绍，fabric内部的负载均衡很重要，需要从负载均衡算法方面进行优化，例如：基于成员接口历史负载情况，选择空闲链路。把出接口队列长度作为流量均衡的hash因子。切割大象流，把一条流切分为多组，调度到不同路径，且保证不乱序。从这三个方面协作处理，实现完美的负载均衡调度
管理面-自适应网络。低时延网络对运维的管理自动化提出更多的要求，相对于低时延网络在丢包、性能方面提出更高的要求，网络运维管理要屏蔽网络环境变化对性能的影响，确保配置永远是最优的。要达到自适应的网络效果，我们认为应该建立分析。第一点是业务的探索和发现，我们要构建自己业务测量的能力，把业务沿途网络节点转发信息进行记录和提取，第二点是计算和特征分析，根据现网实时数据和业务特征，计算出最优的水线阈值和最优策略。第三点是下发和持续的优化。根据业务流量特点，自动配置并动态调整参数，自动下发给服务器和网络设备，实现自适应网络配置。
功能强化-队列优化，数据中心内流量特征有两种，大象流和老鼠流，大象流对时延不敏感，丢包对整体性能影响较小，但是占据了80%的流量，网络拥塞期间，很容易把交换机的队列占满，时延敏感的业务流量被饿死，需要从交换机队列层面优化，将大象流隔离到单独的队列中，为老鼠流预留足够的buffer，以及单独的队列设计，实现设备层面的低时延转发。
以上技术分享就结束了。在低时延网络里面业界也关注很多，也有很多相应的技术，由于时间关系就分享这么多。总结一下今天我的分享。共4个部分，第一部分是业务定位，低时延网络在百度来说主要是面向百度云和人工智能的内生需求，我们分别部署了25G、40G、100G的低时延网络，用来支撑业务需求。从网络定位上面，我们配合整体的网络布局，实现局部的加速的能力。第三点是产品定位，目前低时延网络中仍然有很多问题和挑战，技术的优化空间还很大，在未来也希望跟厂商共同的去探索。第四点是架构演进定位，向大规模网络架构探索，随着技术发展，逐步优化迭代。
大象流和老鼠流
主要是通过流的大小和速率区分。
大象流：大速率，长时的流就是elephant flow，如：虚机的迁移，数据的迁移，MapReduce
老鼠流：小速率，短时的就是mouse flow，如：发邮件，看网页，聊微信
