前言
篆芯智能网络交换机芯片，不仅支持传统的各种传输协议功能外，还将支持针对DPU和AI加速芯片新一代云数据中心需求的新数据中心传输协议(NDP-New Datacenter Protocol)。NDP不但能够完全去除传统协议的历史包袱（如TCP的慢启动，会话的建立及拆除），还能够在网络拥塞的情形下提供高效的告警及缓解机制，进而极大地降低整体交互时延进而提高整体应用的有效性。
近日，篆芯半导体，云豹智能与燧原科技三家公司达成战略合作，依托三方各自在高端数通网络芯片，DPU和AI计算领域的软硬件优势，联合开发基于智能网络基础架构的大规模高性能AI算力平台，为云端AI计算提供更高效的解决方案。
<续前文>
NDP交换机服务模型
前述有提到过CP(Cut Payload)技术，通过把数据丢掉，单纯送包头给对方。其不丢掉报文的原因是希望能够通知接收端关于报文的信息，让接收端可以要求转发端重传。这整体所消耗的时间会比接收端依赖重传Timeout还要短。然而。论文还发现，若采用最原生的CP处理其实会引发下列问题，因此要将其改良以解决这些问题。以下图所示，在9KB jumbo帧的情况下，去探讨应用程序之间的goodput，goodput与throughput的差异是：goodput代表的是应用程序真正接收到的报文量，不包含协议包头以及重传报文所造成的流量。
图中红线的部分代表的是原生CP处理，而蓝线的部分代表则是NDP处理。X轴代表的是网络中有多少条链接种被大量切断的报文(被砍掉内容，只剩下包头)。Y轴代表的是在当前网络下，应用程序真正收到的goodput占理想值多少百分比。(最高100%)。图中实线代表的是所有应用程序的平均goodput，而虚线代表的是10%最差应用程序的平均goodput。先看原生CP的效果，可以明显看到实线的部分，会因为流量愈多，而使整体goodput几乎呈线性下降。而对于虚线来说，整个几乎惨不忍睹，代表后半部分的应用程序根本没有办法拥有好的传输量。
除了上述模拟结果外，原生CP还有一个问题是，采用FIFO机制来收送一般报文与被切断后的报文，这意味者CP想要让接收端尽快地知道有报文要重传，但是这些被截断的报文又要等待交换机内的缓存都被消耗掉才有机会被送出，其实这一来一回对于整体的是会造成一些损伤的。为了解决上述原生CP 带来的问题，NDP提出以下改进：
1.NDP交换机维护两个队列缓冲区，低优先的用于数据传输，高优先的用于被截断报文的传输，ACKS以及NACKS。
2.论文认为这个设计听起来有点奇特，看起来好像反而会让数据报文更晚送出去，但是经过实验证明，高优先的报文到达接收端并且通知送端要重传报文时，通常交换机低优先缓存的报文都还没有全部处理完毕。
3.高优先跟低优先的队列缓存彼此之间采取的是10:1的轮流机制，每送十个高优先报文，就送一个低优先报文，这可以让要重传的报文尽早通知到接收端。
4.为了打破网络中平衡状态(强者恒强，弱者恒弱)，每当低优先队列满载且遇到新报文时，这时交换机会有两个动作(机率分别是 50%)。
将新到的报文截断，送到高优先队列
将低优先最后面的报文截断，送到高优先，而刚进来的报文就送到低优先队列
通过上述两种动作，打破了网络的平衡，这点可以由图2的虚线看到，在NDP 的环境中，即使是效能最差10%应用程序的goodput跟平均也是差不多的。
路由
前述已经提到，NDP想要实现per-packet ECMP而非per-flow ECMP，于是论文提出了两大类方法：
1. 让交换机本身随机决定当前报文该如何转发
2. 让转发端决定当前报文该如何转发
论文实验证明，让转发端去选择报文该如何转发，会比让交换机去随机转发报文来得更有效率，同时因为交换机本身不用去思考该怎样转发报文，每个报文处理的速度可以更快速，因此交换机的缓存可以设置的更小，这对于低延迟的特性有更好的支持。NDP认为，由于网络环境是在数据中心内，网络拓扑的状况都是可以事先知道的，如从转发端到接收端共有哪些路径可以走。因此NDP的处理方式是转发端事先了解到接受端之间有哪些路径可以走，然后每遇到一个报文，就挑一个路径转发，下一个报文就在剩下的路径中随机挑一条去转发，当所有的路径都已经走过一次后，就全部重新来过。
这样的做法有两个优点：
1.通过分散报文到所有路径去转发，能够提升网络整体的使用率，并且减少某条网络成为瓶颈的可能性。
2.每次挑选时都通过类似随机的方式，可避免多个应用程序会使用相同的走法导致网络出现太规律的走法，进而导致使用率不佳或是某些路径过于拥塞。关于由发送端决定当前报文该怎转发，论文提出了三种方法：
1.source-route
2.label-switch
事先规划好哪些label走哪些路径，然后发送端报文上label
3.destination addresses
根据目的端的位置来选择，假如目的端有多个IP地址，则每个地址都可能有不同的走法。
传输协议
接下来详细介绍NDP传输协议的设计。
NDP在设计传输协议时是基于接收端驱动的理念去设计的。希望通过这个设计能够跟之前提过的各式各样技术结合，如multipath forwarding、 packettrimming 以及 short switch queues等。通过与这些技术结合，NDP提供低延迟和高产出的效能。
TCP早期设计是给互联网用的，所以设计理念是悲观的，因为不知道整个网络上每个节点的状况，尽可能的小心去使用。如slow start、三次握手等原则。此外，对于TCP来说，当同时发生网络拥塞丢弃报文，或多重路径路由所导致报文的顺序不一致，这些情况会让TCP无法分辨到底发生什么事情，于是最后只好要求发送端重传，这行为无形间就降低了整体的传输速度。
然而对NDP来说就不一样，由于是在数据中心内，能够事先知道整个网络节点的各情况，因此NDP采取的是乐观的设计理念：
1.收到第一个RTT就转发报文，不等三次握手。
2.一开始就根据当前线路的最大承载量去设定传输速度，假设都没有其他流量使用。
3.不依赖顺序的协议内容
NDP采用了截断报文的方式，通过包头的内容告诉接收端到底哪些报文需要重传，这使得接收端有更明确的信息知道网络发生什么情况，因此报文到达的先后顺序就显得不重要。
下图解释了截断报文的运作模式：
假设从SRC要转发九个报文到达DST，当报文到达DST上层的交换机时，因为交换机的数据缓存(低优先队列)只能承受八个报文。所以第九个报文就被截断了(时间点为T(trim))。接下来通过不同优先队列的设计，被截断的报文可以在 T(header)的时间就马上到达DST，DST在看到包头后就马上知道第九个报文需要重传，因此马上送个信息回到送端。此信息到达发送端的时间点为 T(rtx)，同时交换机还在处理刚才的八个报文，大概处理到第二个左右。当发送端将第九个报文送到交换机时，此时交换机处理到第六个左右，因此数据缓存不但有空间可以容纳第九个报文，同时这过程中也没有任何处于闲置的况状，可以说是将缓存的使用率尽可能的提升。
至此，可以知道截断报文能够告诉接收端哪些报文需要重传。论文认为通过上述的特性与Zero RTT的结合，认为让发送端去决定当收到数据(Zero RTT)后发送端要转发多少报文是最佳的选择。
其设计理念及原则为：
当发送端一开始用全速去转发报文后，接下来就会停止转发报文
等待接收端转发请求要求发送端继续转发报文
接收端可以根据当前本身收送报文的速率(如对外链接上有多条连接导致每条连接都没有办法用到最高速度)，因此会由接收端去决定发送端当前转发速度多快
不论是重传的报文，或是全新的数据报文，接收端都可以要求发送端转发
接收端采用Pull的概念来达到控制发送端的传输速度，接收端会维护Pull队列，供所有连接一起使用
Pull队列内放置的是Pull报文，该报文要标示属于哪个连接，以及计数器，而该计数器则是per-sender的，用来记录当前转发过多少个Pull报文
Pull队列默认会公平地去处理每个连接所对应的Pull报文，不过可以根据连接优先度调整其转发的Pull报文数量，以提高对应送端的传输速度
每个具体步骤如下：
连接开始时，发送端一开始就用全速将报文送往接收端，这些报文都会包含类似TCP的序号
若接收端收到的是被截断的报文，会立刻转发NACK给发送端，要求其将准备重传报文(还不需要重传)
若接收端收到的是数据报文，会立刻转发ACK给发送端，通知其该报文已接收到(清除旧信息，准备新报文，此时也还不会转发)
当接收端收到报文(数据或是截断报文)，都会马上加入一个Pull报文到其Pull队列中
当发送端收到由接收端所转发的Pull报文时，会根据Pull报文内的计数器来决定当下要转发多少报文(可以是重传报文，也可以是新报文)
当发送端将所有报文都转发完毕后，就会将最后一个报文打上标志，当接收端看到此标志时就知道对应的发送端已经没有报文要送了，就将其对应的Pull包移除，避免下次产生不必要的请求传输
若发送端之后又有数据想要传输，则必须主动传输给接收端，而不会通过接收端的Pull报文来取得
根据论文实验数据，其相关设定如下：
交换机的数据缓存只有八个报文
MTU设定为9K (jumbo帧)，
交换机性能为10Gb/s
环境为FatTree
在此环境下，每个报文完整处理的时间为7.2µs，若考虑到优先队列的使用，最差情况下的处理时间是400µs，此数据一般来说其实是非常小的。因此在NDP的环境中，RTO (Retransmission timeout) 可以设计得更小。那NDP如何在Incast的状况下取得好的表现?假设一开始有很多个发送端，每个都用全速传输。可以想象得到的是会有很多报文都被截断，接收方每个对应的接收端都可以采用Pull的概念控制对应发送端的传输速度，就可以让每个发送端的传输速度总和能够符合交换机的处理速度，能够让被截断的报文数量降到最小，甚至没有。
Coping with Reordering
根据Per-packet多重路径路由，对于发送端/接收端来说，数据报文，Pull报文，ACK以及NACK在收到的时，是非常有可能是乱序的。虽然NDP一开始的设计是不用担心这个情况的。
The First RTT
NDP为了达到能够在第一个报文就直接转发数据而不采用TCP的三次握手后转发数据，必须要处理三个问题：
避免遇到大量相同Source IP的垃圾报文影响
(因为TCP有连接认证，没有连接的TCP报文不会被处理，避免被大量垃圾影响)
2.避免同样一条连接多次建立连接
3.处理在第一个RTT之间经由多重路径路由造成乱序的数据报文
目前已知采用First RTT处理方法，如 T/TCP以及TFO(TCP Fast Open)都有一些相关机制，如采用Token或Connection ID来处理上述问题，但是没有一种方法能够同时处理三个问题。这个问题NDP不想处理，认为可通过Hypervisor/NIC之类的方式预防。
在发送端/接收端两边都设计了time-wait的状态。由于per-packet ECMP的关系，第一个到达接收端的报文往往不是第一个送出的报文，为了处理这个问题，发送端第一次送出的报文都会带有一个SYN的标志以及该报文是第一次送出报文中的第几个。通过这个信息就可以让任何一个第一次送出中的任一个报文来建立连接。
Robustness Optimizations
假如网络一切都正常运行，上述NDP其实运作得非常良好，然而好景不常，网络常常会出问题。这种情况下，NDP要怎么处理这些问题来继续保持其提供的低延迟与高输出的特性。常见的问题有：
1. 交换机故障导致报文不通
2. link出问题，突然降速，如从10Gbs降速成1Gbs
论文认为传统的single-path TCP对于这些问题都没有很好的处理方式，会让整体的效能大幅度下降。NDP处理的方式就是采用大量的计数器，去记住每条连接上面关于ACK以及NACK的数量，同时通过per-packet多重路由的方式来转发报文。因此发送端会定期检查，若当下所有可转发路径中，有某些路由上面的计数器数值异常，代表可能出现问题，不论是降速或是网络不通。此时就会将有问题的路由先从候选清单中排除，避免报文走到有问题的路由去。论文认为传统的作法大部分都依赖路由协议去侦测问题并动态修改路由表，这些虽然有效，但要花费太多时间去处理，因此效果不佳。
Return-to-Sender
前述提过，采用CP机制能够有效的解决Incast网络问题，然而当Incast报文过多时，交换机上的两个队列(高/低优先)都可能会被塞满，在这种情况下报文就会被丢弃了。举例来说，高优先队列可以存放1125*64-byte的报文量，而低优先队列只能存放8*9K-byte的报文量。假设发送端转发了一个报文过去，却迟迟没有等到响应，在经过RTO时间后，就会重传报文。根据前述的实验，最大RTT时间是400µs，因此论文认为最大的RTO设定为1ms即可。然而根据10Gbs的传输能力来看，要处理1125*64B的报文大概需要8ms，这意味者重传的报文是可以在队列被消耗完毕前送达到交换机，可以保障不会有交换机处于闲置的状态进而提高整体使用率。
为了追求极致，论文认为，在某些情况下，如高优先报文或数据量极小的报文，当所有的队列都满的情况下，这时候交换机就会采取特别做法，将报文的source IP以及destination IP反转，然后将该header迅速送回给发送端，告诉发送端说有报文要掉了，快重传。这种机制只有在某些特殊情况下，可能网络当下有些问题之类的，想要加快处理速度，避免等待RTO来处理。下图是根据仿真环境得到的数据图：
Y轴是CDF(cumulative distribution function)，X轴纪录的是当发送端送出第一个报文到达其收到第一个ACK所花的时间。此数值包含所有的delay，也包含重传所导致的花费。
Permutation显示的是432-node中每个node都会往下一个node来进行连接，故会有431条连接
Random显示的是432-node中每个node都会随机找一个node来进行连接，故会有431条连接
上述这两个场景都表现不错，能够完整的用满整个FatTree的网络带宽，同时平均的delay约100ms。接下来Incast的情况，则是挑选100 node同时间对同一个node进行转发的实验，变异数则是每个连接的传输大小。可以观察到的，当转发数量只有135KB时，整体的效能是比较差的。原因是每个连接都能通过第一次RTT就将所有的报文转发出去，这情况导致大量的报文被截断甚至超过缓存数量。同时大概只有25%左右的包头被优化给送回给发送端去加速处理。以delay来看，最后一个报文花了11055µs去转发。假设整体转发量更大，到达了1350KB，虽然第一个报文传输的行为会跟135KB的实验一致，但是后续NDP的设计能够让整体后续的处理更为平顺以及更稳，所以其平均的处理时间大概只有 95µs。
拥塞控制
论文认为NDP本身没有任何拥塞控制，因为拥塞控制本身是为了下列两个目的而产生的：
1.避免拥塞崩溃
2.公平
而NDP本身的特性已经完全避免掉上述的问题，所以根本不要再去做没必要的拥塞控制。NDP设计下，每个连接一开始都乐观地采用全速转发，同时因为协议设计的原因，接收端拥有大量关于当前连接的信息，通过pull队列的设计能够让每条连接平均的使用当前网络带宽。论文指出，由于接收端可以决定发送端转发报文的速率，因此若有些连接被标注是高优先的，则可以使用比一般连接更多的流量。这种情况下就是故意造成不公平的，因此也不是大问题。
NDP局限性
论文通过实验证明了在各种流量模式中，NDP提供的效果非常接近于Clos网络架构理论上的效能。在非对证的网络架构中，如BCube、Jellyfish，NDP的表现会稍微差一点，主要是当网络拥塞时，发送端会将报文通过不同距离的路径来传输报文(就不是ECMP了)。在这种情况下，若采用sender-based per-path的多重路由就会有良好的效果。有一篇论文讨论上述的问题：C. Raiciu, S. Barre, C. Pluntke, A. Greenhalgh, D. Wischik, and M.Handley. Improving datacenter performance and robustness with Multipath TCP. InProc. ACM SIGCOMM, Aug. 2011。
对于高负载数据中心来说，当报文数量过多时，会产生发送端发出的报文一直处于被截断的情况，尽管表现不好，但是跟目前已知的协议，如DCTCP比起来，NDP的效能还是胜出。
最后的问题就是环境部署问题，只当哪一天可编程交换机能够广泛部署在数据中心时，要部属NDP就是很容易的事情了。此外，如何跟现有的TCP连接共存也是一个问题，因为NDP目前会吃掉该网络的流量导致 TCP几乎没法使用，因此在可编程交换机端应该要有办法去处理相关的问题。
<全文结束>
希望本文能对了解数通网络设备提供一点粗浅的感性认识。
本文有关信息均来自公开资料。