前言
篆芯智能网络交换机芯片，不仅支持传统的各种传输协议功能外，还将支持针对DPU和AI加速芯片新一代云数据中心需求的新数据中心传输协议(NDP-New Datacenter Protocol)。NDP不但能够完全去除传统协议的历史包袱（如TCP的慢启动，会话的建立及拆除），还能够在网络拥塞的情形下提供高效的告警及缓解机制，进而极大地降低整体交互时延进而提高整体应用的有效性。
近日，篆芯半导体，云豹智能与燧原科技三家公司达成战略合作，依托三方各自在高端数通网络芯片，DPU和AI计算领域的软硬件优势，联合开发基于智能网络基础架构的大规模高性能AI算力平台，为云端AI计算提供更高效的解决方案。
目前较为全面的讨论NDP的文献为：
M. Handley, C. Raiciu, A. Agache, A. Voinescu, A. W.Moore, G. Antichik, and M. Mojcik. Re-architecting Datacenter Networks andStacks for Low Latency and High Performance. In Proceedings of the ACM SIGCOMM2017 Conference, SIGCOMM ’17, pages 29–42, New York, NY, USA, 2017.ACM.
鉴于NDP是较为前沿的网络新技术，本文将对该论文进行解读。
正文
本论文所发生的场景是在数据中心内，不适用于一般的互联网，主要是因为互联网充满太多未知性与无法掌控的装置，譬如每条链路的带宽, 交换机的配置等。有这些未知的情况下，无法设计一个好的运作模式来满足低延迟与高转发率的需求。因此环境都只考虑数据中心。
论文提出了NDP(New Datacenter ProtocolArchitecture)概念，其具体目标，评比对象以及实作方法如下。
论文设定目标：
对于short-flow有尽量低的延迟
对于long-flow有尽量高的转发率
在高负荷网络中，利用网络拓扑链路来传输报文
将incast情况对网络造成的影响降到最小
论文研究对象：
DCTCP(Datacenter TCP)
MPTCP(Multi Path TCP)
DCQCN(Datacenter QCN)
论文实现方法：
用DPDK开发NDP Application (抛弃 TCP, 重新开发L4协议)
从硬件方面，在NetFPGA SUME上开发NDP相关功能
从软件方面，在P4上开发NDP相关功能
摘要
近年来数据中心蓬勃发展，为了能够在内部提供更良好的网络效能，不论是低延迟或是高输出，网络架构从早期的三层式体系结构(Fat tree)逐渐都转换成Clos架构，然而传统的TCP协议在设计上并不是针对数据中心设计的，故其设计原理导致其不能满足需求。
因此论文提出了NDP (new data-center transport architecture)，其能够提供 short transfer接近完美的传输时间，同时对于广泛的应用情况，如Incast下亦能够提供很高的传输效能。
NDP架构下，交换机采用浅缓存来存放报文，当缓存满载时，不同于传统的将报文丢弃的做法，NDP采取的是截断报文的内容(payload)，只保留该报文的包头，并且将此报文设定为高优度优先转发。这种作法让接收端能够有更完整关于转发端的信息，能够动态的调整传输速度。
论文将NDP概念和软件，硬件相结合。使用的技术与硬件分别包含了 DPDK、P4 以及 NetFPGA。
最后论文进行了一系列效能评比，用大规模的模拟证明了NDP能够为整个数据中心提供低延迟与高输出的特性。
介绍
随着数据中心爆炸性的成长，为了满足其内部传输的需求(低延迟/高输出)，有各式各样的新方法或是在旧有技术的改进用来满足上述需求。譬如TCP改进的 DCTPC、本来就存在已久的MPTCP甚至是RDMA(RoCE)。在RDMA网络环境中，为了减少报文丢弃对整体传输造成的影响，都会将整个网络传输打造成无损环境，为了达成该目标，可以采用Ethernet Flow Control， Explicit Congestion Notification(ECN)或是Priority Flow Control(PFC)。微软在SIGCOMM 2016发了一篇关于RDMA+PFC问题的论文。其认为虽然 PFC可以用来控制转发报文的速率，藉此达到无损的网络环境，但是一旦整体网络处于高度拥塞的情况时，数据报文与PFC控制报文对带宽的争夺会使整体网络没有办法继续提供低延迟的优点，最后的结论是：“how to achieve low network latency and high network throughput at the same time forRDMA is still an open problem.“ 本论文提出了一个不同与以往思路的新协议NDP来满足上述的要求。
NDP不同于TCP，不需要先通过三次握手来进行连接才可以传输报文，同时也避免了TCP slow start 机制，可以连接一开始就采用全速的方式去转发报文。此外，NDP采用了per-packet multipath而不是per-connection multipath 的方式，同时通过NDP协议的方式避免连接中报文乱序所产生的问题。
对于支持NDP的交换机来说，采用了类似CP(CutPayload)的机制，当交换机缓存满载的情况下，对于接下来收到的报文不会直接丢掉，而是会将其 Payload移除，并且设定高优先度的方式将其包头尽可能快速的转发到目的地，让接收端能够有信息了解到当前网络与转发端的状态。
通过CP机制可以对metadata达到近乎无损的效果，不过对于数据来说则没有办法。由于NDP协议本身设计的方式，报文丢弃所产生的影响并不会像TCP 一样有如此严重的影响。
设计空间
对于内部使用的数据中心而言，其网络流量大部分都是属于Request/Reply,这种类似RPC方式的流量。这意味者以网络使用率来看其不会一直处在满载的状况，但是对连接接收端的应用程序(如服务器)来说，其所收处理的网络流量可能是大数据的传输，也可能是简单数据的短暂连接。对于短暂连接来说，最大的重点就是低延迟，尽可能快的传输回去。
为了处理这个问题，目前有许多应用程序采取reuse TCP连接来处理多个请求，以此方式减少TCP三次握手所产生的延迟。然而，是否存在一种架构，不论当前整个网络系统是否处于高流量负载，该架构能够让应用程序不需要重复使用连接，让每个request都是一条全新连接，同时又能够接近完美的延迟(意味者不会像TCP 都要先经过三次握手才可以开始传数据)。于是NDP的设计理念就出现了，为了达到上述的要求，首先必须要重新思考，当前网络架构中，是什么因素阻碍了上述要求，这些阻碍该如何克服。
端到端服务请求
论文列出了如下数据中心内应用程序要追求的特性。
位置独立
分布式应用程序运行于数据中心内的任一机器上，都不应该要影响应用程序本身的功能。由于目前都采用Clos网络架构来设计网络拓扑，所以整个网络拓扑是能够提供足够的流量来使用，而不会变成一个理由或是瓶颈使得应用程序必须要选择特定的机器才可以运行。
低延迟
虽然 Clos网络架构能够提供足够的带宽给拓扑内的服务器，对于流量的负载平衡能提供良好的效果，但是对于短暂连接来说，并没有办法提供低延迟的能力。
论文认为虽然能够提供高流量输出是一个很重要的议题，但是能够提供低延迟的能力则是更重要且优先度更高。
Incast
Incast这个专有名词的介绍可以参考Data Centersand TCP Incast – Georgia Tech – Network Congestion，简单来说就是同时间有大量请求进到数据中心内，这些请求都会产生对应的reply，然后这些reply连接同时间一起进入到交换机内，这会使得交换机的缓存区立刻满载而没办法继续承受报文，导致部分的TCP连接需要降速重传。
论文认为一个好的网络架构遇到这种问题时，应该要能够保护后台的应用程序连接，让这些连接应该要尽可能地维持低延迟性。
优先级
假设有一应用程序，同时会转发不同的请求到后台去处理，而这些请求所产生的reply本身是有依赖的关系。所以假如这多个reply没有依照当初转发请求的顺序回来的话，在应用程序端就必须要特别去处理，譬如说不要同时送多个请求，不过这样就没有更好的效能表现。因此对于应用程序来说，若本身能够有一个优先级的机制，能够决定哪些报文要先处理，就可以解决上述的问题，而让应用程序本身就可以更自由的去处理。
传输协议
目前数据中心内部采用的传输协议虽然可以处理上述应用程序的问题，但是为了处理那些问题，反而会失去下列特性。而NDP本身在设计时，希望能够在满足上述应用程序的需求，同时又保有下列的特性。
Zero-RTT连接建立
目前主流的TCP协议在转发数据前，必须要先进行三次握手，这意味着当数据送出去前，至少要先花费 RTT*3 的等待时间。对于低延迟的应用程序来说，希望能够达到RTT*0，至少RTT*1的等待时间就能够将数据送出，这对NDP来说，在数据转发前，整个连接不需要有三次握手的动作，一开始就直接送出数据。
快启动
数据中心不同于互联网的地方在于网络拓扑中的每个交换机都是自己掌握的。所以TCP采用的慢启动SlowStart 其实对于数据中心来说是没有效率的，毕竟一开始知道可用带宽是多少，不需要如同面对互联网那样的悲观，慢慢地调整窗口大小，而是可以一开始就乐观的转发最大单位，再根据状况进行微调。若采取这种机制，则应用程序可以使用更快的速度去转发报文。
Per-packet ECMP
在Clos网络架构中，错综复杂的连结状态提供了Per-flow ECMP一个很好发挥的场所，可以让不同的连接走不同的路径，藉此提高整体网络使用率。然而如果Hash的结果相同的话，其实是有机会让不同连接走相同的路径，即使其他路径当前都是闲置的。若采取MPTCP这种变化型的TCP来处理的话，该协议本身的设计可以解决上述问题，但是对于短暂流量或是延迟性来说，却没有很好的效果。为了解决这个问题，可以将Per-flow ECMP转换成Per-Packet ECMP。因此 NDP本身协议的设计就是以Per-Packet ECMP为主的。
Reorder-tolerant握手
假设已经有了Zero RTT以及Per-packet ECMP两种特性，则新连接的报文可能就会发生乱序的情况，收送顺序不同的状况下，若对于TCP来说，就会触发拥塞控制的机制进而导致降速。因此NDP在设计时，必须要能够处理这种状况，可以在不依赖报文到达先后顺序下去处理。
Optimized for Incast
即使整个数据中心的网络环境，如带宽等信息一开始就已经可以掌握， Incast问题还是难以处理，毕竟网络中变化太多，也许有某些应用程序就突然同时大量产生报文，这些报文同时到达交换机就可能导致报文被丢弃。因此NDP本身在设计时，也希望能够解决这个问题。
交换机服务模型
在数据中心内，除了应用程序特定，传输层协议之外，还有一个特性也是很重要的，这个特性与上述两个特性关系紧密，一起影响整个网络的运作，这个特性就是交换机服务模型。论文认为在这特性中，最重要的就是当交换机端口发生阻塞时会怎么处理，这个特性会影响到传输层协议以及拥塞控制算法的设计，甚至是传输相关的特性，如per-packet ECMP都可能会被影响到。论文指出，目前有很多种预防拥塞的机制，如Loss as a congestion，Duplicate or selective Acks等，其中Duplicate or selective Acks会主动触发重传，这种技巧对于长时间连接来说是好的，但对于需要低延迟的短暂连接来说是不好的，主要是这些重传都会经过RTO(Retransmission timeouts)，这个时间的长短会产生一些负面的影响，因此也不是一个万用的解法。
ECN(Explicit CongestionNotification)的出现对拥塞状况提供了不少改进，如DCTCP(data center TCP)就采用了该技术来辅助。该技术对于长时间的流量来说，能够有效的减少报文丢弃的数量，然而对短暂流量来说却没有太大的帮助，因为短暂流量太短暂了，根本来不及去接收ECN报文并处理。在现实情况中，交换机本身会采用较大的缓存来处理报文以及ECN报文，这种设计对于Incast的现象能够有效地减缓报文被丢弃的情形。但也因为缓存太大，每个报文在交换机内待的时间就会更长，因此重传机制的时间就会被拉长，导致延迟过大。
除此之外，对于无损以太网传输来说，则是会通过802.3X的PauseFrame或是802.1 Qbb的PFC (PriorityFlow Control)。这类技术都是通过控制报文阻止转发端停送报文，降低报文丢弃的数量。但该技术也不是十全十美的，以PFC来说，在一个高负荷的网络中，有可能会有两条不同的连接根据Hash导向走向相同，同时这两个连接最初的设定是相同的优先度，则有可能会因为一条连接的拥塞进而导致其他连接也被影响到。
上述这些拥塞制的设计除ECN之外，其余的对于Per-packet ECMP都没有能够提供良好的效果。
论文最后，提到了一种称为CP(Cut Payload)的做法，这种机制就是当拥塞发生时，不丢弃整个报文，而只是丢弃报文的数据，而保留报文的包头。当应用程序端收到只有包头，没有数据的报文，就可以知道这个当前线路有拥塞问题，可以进行相应的处理。
这种情况下，就可以避免减少RTO对于重传造成的时间延迟。然而这种设计也有两个问题(毕竟CP是1994提出的论文)
1．交换机采用FIFO机制，所以这些被丢掉数据的报文，也是要慢慢等待交换机将报文处理完毕才可以往外转送，这就会大幅增加这些报文的RTT时间。
2.该设计是基于single-path传输，没有考虑到多条路径传输，不论是per-packet或是per-flow的ECMP。
至此，可以归纳出作者心目中的完美协议了，简单回顾一下：
1.对于短暂流量能够提供低延迟，低延迟，低延迟
2.对于长时间流量尽量能够提供高流量输出
3.per-packetECMP
4.遇到Incast等情况也能够继续保持低延迟
后文会讨论NDP到底如何处理才能尽可能地有提供上述功能。
设计
为了满足上述的条件，NDP在设计时就决定整个设计要包含完整的架构，这包含了：
1.交换机的行为
2.路由
3.全新的传输协议
下图是展示了NDP的整体架构，通过全新设计的NDP架构，能够满足该图中的每个特性。下面将简单介绍每个模块的功能。后面的章节才会详细叙述其设计方法。
对于Clos网络架构来说，因为网络内拥有多条错综复杂的链接，因此整体网络的带宽是足够的。这对于想要执行负载均衡的应用来说是绰绰有余的，然而为了避免流量都流经相同的路径，导致某些路径上有大量的流量，进而导致报文丢失，并且对于延迟性与流量输出都有影响，必须要采取必要的措施将连接分散到不同的路径之中。
此外，对于短暂连接来说，per-packet的ECMP相对于per-flow来说更有意义，但是per-packet的ECMP必定会遇到报文顺序不同产生的乱序情况。
为了满足短流量低延迟的效果，转发端不能利去探测当前网络的带宽来决定转发速度，必须要在第一个报文就将数据送出，也就是所谓的Zero RTT。对于交换机来说，要达到低延迟，则缓存不能够太大，否则报文待在缓存内的时间过长，就会导致该报文要花更长的时间才能够被送过去。在小缓存的情况下，报文数量一多则缓存就会马上爆满。当报文丢弃同时加上因为per-packet ECMP所产生的报文乱序问题，会使接收端难以处理这些问题，无法辨别当前没有收到报文到底是什么原因。若想要避免报文丢失，则交换机的缓存就要够大，如采取pause frame，亦或是PFC这类型无损网络。然而这类技术都会因为当前连接产生的拥塞判断去影响网络中其他连接，这就会使某些连接没有办法达到低延迟的效果。所以NDP设计的理念是一种介于无损与有损的概念。
论文还采取Packet Trimming，其设计理念与CP（Cut Payload）极为相似，此种情况下，交换机采用小缓存，当接收端发现报文只有包头没有内容时，就可以判断当前网络有拥塞发生。为了可以让重传时间尽可能的快，对于这些被截断内容的报文，交换机应尽可能的快让该类型的报文转发出去。这类型的报文到达接收端后，会让接收端有信息可以知道当前哪些应用的报文到达，藉由这些信息加上一个完整的报文池(receiver-pulled pool)，接收端就可以精准地控制哪些报文要优先处理。
<未完待续>
希望本文能对了解数通网络设备提供一点粗浅的感性认识。
本文有关信息均来自公开资料。