暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

(SIGCOMM最佳论文)NDP:重新设计数据中心网络和协议栈以实现低延迟和高性能

1896
点击上方蓝字 关注我吧


内容提要

现代数据中心网络通过冗余CLOS拓扑和低交换机延迟提供非常高的容量,但传输协议很少提供匹配的性能。本文介绍了NDP,一种新的数据中心传输体系结构,它可以在包括incast在内的各种场景中为短传输和高流量吞吐量(short transfer and high flow throughput)实现接近最佳的完成时间。NDP交换机缓冲区非常浅,当它们填满交换机时,会将数据包修剪到报头(去掉payload),并优先转发报头。这使接收端能够全面了解来自所有发送方的即时需求,并且是我们新颖、高性能、多路径感知传输协议的基础,该协议可以优雅地处理大量的incast事件,并在RTT时间尺度上优先处理来自不同发送方的流量。我们使用DPDK在Linux主机、软件交换机、基于NetFPGA的硬件交换机和P4中实现了NDP。我们在我们的实现和大规模仿真中评估了NDP的性能,同时展示了对非常低延迟和高吞吐量的支持。




1、引言



数据中心在过去几年中发展迅速,CLOS拓扑结构变得很常见,新的重点是低延迟,首先是改进的传输协议,如DCTCP,最近是解决方案,如RDMA over Converged Ethernet v2,在交换机中使用以太网流量控制,以避免拥塞造成的数据包丢失。

在轻负载网络中,以太网流控制可以为主导数据中心工作负载的请求/响应流提供非常好的低延迟性能。数据包是排队的而不会被丢弃,如果必要的话会产生反压,在多个交换机之间暂停转发,因此不会浪费时间在启动时过于保守或等待重新传输超时。然而,根据微软部署RoCEv2的经验,Gau等人指出,无损网络不能保证低延迟。当发生拥塞时,队列会增加,并生成PFC暂停帧。

队列和PFC暂停帧都会增加网络延迟。他们得出结论:“如何同时实现RDMA的低网络延迟和高网络吞吐量仍然是一个开放的问题。”本文提出了一种新的数据中心协议体系结构NDP,它采用不同的方法同时实现低延迟和高吞吐量。NDP没有握手进行连接启动,允许流以全速率立即开始发送。

我们使用逐包多路径负载平衡,它以重新排序为代价避免核心网络拥塞,而在交换机中使用类似于剪切有效负载(CPCut Payload)的方法,该方法在交换机队列填满时删除数据包的有效负载。这使得网络对于元数据是无损的,但是对于流量有效负载则不是。尽管进行了重新排序,无损元数据还是为接收端提供了入站流量的完整视图我们可以利用它构建了一个全新的传输协议,该协议实现了短流的极低延迟,即使在病态流量模式下,到达不同目的地的流之间的干扰也最小。

我们已经在Linux主机、软件交换机、基于NetFPGA SUME的硬件交换机、P4和仿真中实现了NDP。我们将证明NDP实现了:

  • 短流性能优于DCTCPDCQCN

  • 在负载繁重的网络中,交换机队列只有8个数据包,超过最大网络容量的95%

  • incast场景中近乎完美的延迟和公平性。

  • 到不同主机的流之间的干扰最小。

  • inccast期间对散乱通信进行有效的优先排序。




2、NDP设计空间



数据中心内部网络流量主要由请求/响应类RPC协议组成。平均网络利用率很低(也有冲高的概率,只是很少),但应用程序可能非常突发。现今的大问题是延迟,特别是对于类似RPC的短工作负载。现今的应用程序常常在多个请求之间重用TCP连接,以分摊TCP握手的延迟成本,这是以线端阻塞队头阻塞为代价的。

有没有可能对协议栈进行改进,使每个请求都可以使用一个新的连接,即使在负载很重的情况下也可同时期望接近底层网络的原始延迟和带宽?我们将展示这些目标是可以实现的,但要做到这一点,需要改变流量的路由方式,交换机如何应对过载,最重要的是,需要一个与当前使用的传输协议完全不同的传输协议。在下一节描述我们的解决方案之前,我们首先强调必须考虑的关键架构点。

2.1 端到端服务需求


应用程序希望从数据中心网络得到什么?

位置独立性/无关性。分布式应用程序的元素在数据中心的哪台机器上运行并不重要。这通常是通过使用高容量并行CLOS拓扑来实现的。这种拓扑具有足够的横截面带宽,因此核心网络不应成为瓶颈。

低延迟CLOS网络可以提供带宽,解决路径间负载平衡的模块化问题,但在提供低延迟服务方面往往存在不足。可预测的极低延迟请求/响应行为是关键的应用程序需求,也是最难满足的。这比大文件传输性能更重要,尽管仍然需要高吞吐量,尤其是对于存储服务器。策略必须是首先优化低延迟。

Incast。数据中心工作负载通常需要向大量工作机器(workers)发送请求,然后处理他们几乎同步的响应,从而导致称为incast的问题。一个好的网络协议栈应该在提供低延迟的同时,优雅地保护应用程序免受incast流量模式的副作用。

优先接收端同时处理对应于不同请求的许多传入流也是常见的。例如,它可能向工作机器发出了两个不同的请求,对这些请求的响应现在到达,第一个请求的最后一个响应与第二个请求的第一个响应重叠。许多应用程序需要获得对请求的所有响应才能继续。一个非常理想的特性是接收端能够优先处理来自散乱的到达流量。接收端是唯一能够动态地对其入站流量进行优先级排序的实体,这会影响协议设计。

2.2 传输协议


当前的数据中心传输协议满足了其中一些应用需求,但满足所有这些需求对数据中心传输协议提出了一些不寻常的要求。

RTT连接设置。为了尽量减少延迟,许多应用程序希望小传输small outgoing transfersRTT传递为零(或者请求/响应为一个RTT)。我们需要一个协议,它不需要在发送数据之前完成握手,但这会带来安全性和正确性问题。

快速启动。零RTT交付zero-RTT delivery的另一个含义是,传输协议不能探测可用带宽以最小化延迟,它必须假设带宽可用,乐观地发送完整的初始窗口,然后在不可用时做出适当的反应。与互联网相比,在数据中心环境中,更简单的解决方案是可能的,因为链路速度和网络延迟(排队延迟除外)通常可以提前知道。

逐包ECMPCLOS拓扑的一个问题是,对路径的流进行per-flow ECMP哈希可能会导致意外的流冲突;一些部署发现,吞吐量降低了40%。对于大型传输,多路径协议(如MPTCP)可以建立足够的子流来查找未使用的路径,但它们对很短传输的延迟几乎没有帮助。这里唯一的解决方案是在每个包的基础上跨多条路径传输。这使得传输协议设计复杂化。

重排序容忍的握手/Reorder-tolerant handshake。如果我们在CLOS网络中使用逐包多路径转发执行零RTT传输,即使第一个包窗口也可能以随机顺序到达。这种效果对连接设置有影响:到达的第一个数据包将不是连接的第一个数据包。这样的传输协议必须能够建立连接状态,无论初始窗口中的哪个包最先到达。

针对Incast优化/Optimized for Incast。尽管CLOS网络为核心容量提供了良好的资源,但当应用程序同时向多个工作机器扇出fan out请求时,incast流量可能会使任何传输协议的使用变得困难。这样的业务模式可以导致高分组丢失率,特别是当传输协议在第一RTT很激进时。要优雅地处理这个问题,需要交换机的帮助。

2.3 交换机服务模型


网络交换机的应用需求、传输协议和业务模型是紧密耦合的,需要进行整体优化。特别相关的是交换机端口阻塞时会发生什么。交换服务模型极大地影响了协议和拥塞控制算法的设计空间,并与转发行为紧密耦合:逐包多路径负载平衡是理想的,因为它最小化了热点,但它使终端系统推断网络拥塞的能力复杂化,并增加了处理过载行为的重要性。

丢包作为一种拥塞反馈机制,其优点是丢包不占用瓶颈带宽,丢包只影响通过拥塞链路的流——并非所有方案都具有这些特性。缺点是它会导致数据包结果的不确定性。用于触发重传的重复或选择性ACK只适用于长寿命流。对于短流,尾丢弃是很常见的,然后您必须返回到重新传输超时(RTO)。只有当您能够限制网络中的延迟时,短RTO才是安全的,因此您需要维护短队列,这反过来又会限制您可以使用的拥塞控制方案。丢包也与逐包多路径转发严重耦合;由于流中的数据包到达的顺序不对,因此丢包检测非常复杂——快速重传通常是不可能的,因为数据包到达的整个窗口顺序不对的情况并不少见。

ECN有很大的帮助。DCTCP使用ECN和一个用于分组标记的阈值,以及一个旨在推进和退出标记机制的拥塞控制方案。这大大减少了长寿命流的损失,并允许使用小缓冲区,减少排队延迟。不过,对于短流,ECN的好处较小,因为流没有时间对ECN反馈做出反应。在实践中,交换机与ECN结合使用大型共享缓冲区,这减少了incast丢包,但重传计时器的攻击性必须更小less aggressive。尽管ECN逐包多路径转发的交互非常好,但它确实具有优势,因为传输协议设计可以容忍重排序。

无损以太使用802.3X暂停帧Pause frame802.1 Qbb基于优先级的流控制(PFC)的无损以太网可以防止丢包,避免协议中对攻击性RTO的需要。在低利用率下,这可以有效地实现低延迟——突发将链路可以转发的最大速率达到,而不需要等待重传。问题来自分层拓扑中的更高利用率,其中碰巧哈希到同一输出端口的流,在802.1Qbb的情况下使用相同的优先级,可能会导致输入端口暂停。这会对通过同一传入端口、目的地为不同输出端口的其他流造成附带损害。对于较大的incast,暂停可以向核心交换机级联。无损以太网也会与逐包多路径转发产生严重的交互作用,因为不同的交换机可能会在不同的时间暂停流量,从而加剧重新排序并使终端系统设计复杂化。

Cut PayloadCP试图在不完全无损的情况下获得无损的好处。它丢弃数据包有效负载,但不丢弃数据包头,减轻了过载,同时避免了数据包结果的不确定性。它显示出巨大的前景,但有两个问题。首先,在严重过载的情况下,它很容易发生拥塞崩溃,其中只有报头被转发。其次,因为报头是以FIFO方式排队的,所以尾部“丢失”至少要花费一个RTT。此外,最初提出的CP对每个流使用单路径转发。



3、NDP的设计



我们的主要目标是短流的低完成延迟,以及更长流的可预测高吞吐量。为了完全满足这些目标,NDP影响整个堆栈,包括交换机行为、路由和一个全新的传输协议。我们以一个简洁但简化的设计原理来说明图1中的各个部分是如何组合在一起的,然后在本节的其余部分中补充详细信息。

CLOS拓扑在核心交换机层中有足够的带宽来满足所有需求,只要它是完全负载平衡的。为了避免核心链路上的流冲突(这会影响延迟和吞吐量),跨多条路径的每个流的负载平衡至关重要。平衡短流需要每个数据包的多路径负载平衡,但不可避免地数据包将被重新排序。

为了实现最小的短流延迟,发送者不能在发送之前进行探测:他们必须第一个RTT以线速率发送数据。这在大多数情况下都很有效。当发送方执行逐包多路径负载平衡时,如果以线速率发送导致拥塞,这是因为多个发送方发送到同一个接收端。即使这样,接收端的链路也被完全占用,因此这本身不是问题。

为了保证低延迟,交换机队列必须很小。这意味着冲突流将溢出队列。数据包丢失,再加上多路径重新排序,使得无法推断发生了什么,并且无法足够快地重新传输以避免影响延迟;这违反了低延迟目标。完全防止丢包增加了排队时延;如果这是通过暂停入站流量来实现的,就像使用无损以太网一样,这会影响其他不相关的流量,违反其低延迟和可预测的高吞吐量目标。我们在丢包和无损之间寻找一个中间地带

CP执行的包修剪类似,包修剪就是这样一个中间地带。交换队列可以很小,并且接收端仍然通过检查它接收到的经过修剪的报头来发现发送了哪些数据包。然而,为了最小化重传延迟,需要对修剪的报头和控制包进行优先级排序。到达的消息头告诉接收者确切的需求是什么,因此通过使用接收者主动取数据的协议receiver-pulled protocol,接收者可以精确地控制传入的流量。这避免了持续的过载,并允许更重要的数据包首先被拉取过来完全由接收者决定。

3.1 NDP交换机业务模型


对于CP,当交换机上的队列超过固定阈值时,交换机不会丢弃数据包,而是减掉数据包负载,只对报头进行排队。其基本原理是数据包不会自动丢失,从而允许在不等待超时的情况下快速重新传输。由于数据中心网络的距离较短,这种重传可以很快到达。

除了交换机的改变,CP还建议对TCP进行一些小的改变,以提高incast性能。我们希望超越CP,使用包修剪作为一个非常积极的网络架构的基础,专注于非常低的延迟服务。然而,如果使用CP,可能会出现一些问题。

首先,CP可能遭受一种形式的拥塞崩溃。图2显示了当数据包以远高于传出链路所支持的速率到达交换机时会发生什么。许多无响应流汇聚在10Gb/s链路上,该链路只能支持其中一个,就像在极端的服务器incast场景中一样。这个显示了理想的公平份额的百分比。CP流的平均goodput降低,因为越来越多的链路被修剪的包头占用。此图显示了CP的最佳情况,即9KB的巨型帧(jumbogram。对于1500字节的数据包,崩溃速度要快得多。

其次,数据中心网络非常规则,因此可能会出现相位效应phase effects,从而导致不公平的吞吐量。图2中的虚线显示了表现最差的10%流的平均goodput。相位效应可以使CP非常不公平,尽管我们注意到这个图显示的是仿真结果;现实世界中的相位效应有时可以通过OS调度引起的分组传输的时间变化时间差异)来减小。

最后,CP的目标是提供低延迟的反馈,即数据包已经丢失。但是,由于CP使用FIFO队列,因此只有在接收到所有前面的数据包之后才能发送反馈,从而导致在引发重新传输之前出现延迟。我们希望在交换机中运行非常小的缓冲区,使其中一个队列溢出,并使重新传输在队列有机会耗尽之前到达。这是先进先出排队不可能达到的目标

NDP交换机对CP做了三个主要更改:首先,NDP交换机维护两个队列:一个低优先级的数据包队列和一个高优先级的修剪头、ACKNACK队列。这似乎有悖常理,但它提供了最早可能的反馈,指出数据包没有成功,通常允许在有问题的队列有时间耗尽之前到达重新传输。这至少可以提供与无损以太网一样好的低延迟行为,而不会因暂停而造成附带损害。

其次,交换机在高优先级的“报头队列”和低优先级的“数据包队列”之间执行加权轮询(weighted round robin。由于报头与数据包的比率为10:1,这就允许在不易发生拥塞崩溃的情况下进行早期反馈。

最后,当数据包到达且低优先级队列已满时,交换机以50%的概率决定是修剪新到达的数据包,还是修剪低优先级队列尾部的数据包。这就打破了相位效应。图2显示了NDP交换机如何避免CP崩溃,以及如何避免强相位效应。

3.1.1 路由


我们希望NDP交换机执行逐包多跳转发,以便在源和目标之间可用的所有并行路径上均匀分布流量突发。这至少有四种方式:

•执行逐包ECMP;交换机为每个数据包随机选择下一跳;

•明确源路由流量Explicitly source-route the traffic

•使用标签交换路径;发送者选择标签;

•目的地地址指明要采用的路径;发送方在目标地址之间进行选择。

出于负载平衡的目的,后三种方法是等价的,发送方选择一条路径,它们在发送方表示该路径的方式上有所不同。我们的实验表明,如果发送者选择路径,相比交换机随机选择路径他们可以做更好的负载平衡。这允许使用稍小的交换机缓冲区。

Internet不同的是,在数据中心中,发送者可以知道拓扑结构,从而知道有多少路径可以到达目的地。

每个NDP发送方获取到目的地的路径列表,随机排列,然后按此顺序在路径上发送数据包。在每条路径上发送一个数据包之后,它会再次随机排列路径列表,并且该过程会重复。这样可以在所有路径上均匀地分布数据包,同时避免两个发送方之间的意外同步。这种负载平衡对于实现非常低的延迟非常重要。如果我们使用非常小的数据包队列(只有8个包),我们的实验表明,这种简单的方案逐包随机路径选择可以增加网络的最大容量高达10%以上。

根据网络是L2交换还是L3交换,可以使用标签交换路径或目标地址来选择路径。例如,在L2 Fat-Tree网络中,标签交换路径只需要设置到每个核心交换机,目标L2地址从那里接管,因为Fat-Tree只有一条从核心交换机到每个主机的路径。在L3 Fat-Tree中,每个主机获得多个IP地址,每个核心交换机一个IP地址。通过选择目的地地址,发送方选择包所经过的核心交换机。

3.2 传输协议


NDP使用一个接收端驱动的传输协议,专门设计来利用多路径转发、数据包修剪和短交换队列。每一步的目标是首先最小化短传输的延迟,然后最大化大传输的吞吐量。

当启动连接时,传输协议可能是悲观的/保守的,比如TCP其仅假设有最小的空闲网络容量。TCP三次握手完成后开始发送数据,最初有一个小的拥塞窗口,并在每个RTT中加倍,直到它填满管道。在因特网上,慢启动是合适的,因为在因特网上,rtt和链路带宽有几个数量级的不同,而且更具攻击性的后果是严重的。不过,在数据中心中,链路速度和基准RTT要均匀得多,而且可以提前知道。此外,网络利用率通常相对较低。在这样的网络中,为了最小化延迟,我们必须保持乐观,并假设有足够的容量在连接的第一个RTT中发送一个完整的数据窗口而不进行探测。如果交换机缓冲区很小,在低延迟数据中心环境中,给定光延迟和跳数的速度,完整窗口可能只有大约12个数据包。

但是,如果发现容量不足,数据包将丢失。对于正常的传输协议,逐包多路径转发和在第一个RTT中具有攻击性的组合会导致混淆/混乱。有些包到达了,但顺序是随机的,有些没有。不可能很快知道实际发生了什么,因此发送方必须依靠保守的重传超时来纠正这种情况。

增加交换机缓冲可以在一定程度上缓解这种情况,但代价是增加延迟,但不能防止大规模incast丢包ECN也不能防止激进地发送短流出现的丢包状况。暂停帧可以防止丢包,在这里可能会有很大帮助,但这会给不相关流带来延迟方面的重大问题。

这就是NDP交换机中的数据包修剪真正发挥作用的地方。到达接收端的经过修剪的数据包的报头消耗很少的瓶颈带宽,但是精确地通知接收端发送了哪些数据包。在推断发生了什么时,数据包到达的顺序并不重要。优先级队列确保这些报头快速到达,并且返回给发送方的NACK等控制包快速到达;事实上,足够快的速度引发一个在溢出队列有时间耗尽之前到达的重传,这样链接就不会空闲。这如图3所示。在时间t_{trim},来自九个不同来源的数据包几乎同时到达ToR交换机。到达目的地链路的8个数据包队列填满,来自源9的数据包被修剪。

在包1完成转发后,包9的报头得到优先处理。在时间t_{header}它到达接收端接收端产生一个NACK包。包9在时间t_{rtx}被重传,并且在包7仍在被转发时到达ToR交换队列。到目的地的链路从不空闲,数据包9到达目的地,如果PFC通过暂停上行交换机来防止其丢包的话,它也会在同一时间到达目的地。

在采用逐包多路径的CLOS拓扑中,唯一可以引起队列堆积的热点是来自多个源的流量在接收端上聚合时。对于NDP,修剪的报头表示对接收端的精确需求;它确切地知道哪些发送者想要向它发送哪些数据,因此它最适合在连接的第一次RTT之后决定要做什么。在以线路速率发送完整的数据窗口后,NDP发送停止发送。从那时起,协议由接收者驱动。NDP接收端从发送方请求数据包,对这些请求的发送进行调整pacing,以便它们引出的数据包以与接收端的链路速度相匹配的速率到达。请求的数据可以是经过修剪的数据包的重新传输,也可以是传输其余部分的新数据。因此,该传输协议的作用如下:

  • 发送方在不等待响应的情况下发送完整的数据窗口。数据包携带数据包序列号。

  • 对于到达的每个报文头接收端立即发送NACK以通知发送者准备数据包以便重新传输(但尚未发送)。

  • 对于每一个到达的数据包,接收端立即发送一个ACK,通知发送者该数据包已经到达,因此可以释放缓冲区。

  • 对于每个到达的报头或数据包,接收端将一个拉数据包PULL packet添加到其拉队列中,该拉队列将在适当的时候发送给相应的发送方。一个接收端只有一个拉队列,由它作为接收端的所有连接共享。

  • 拉入数据包包含连接ID和每个发送方的拉入计数器(pull counter),该计数器在发送给该发送方的每个拉入数据包上递增。

  • 接收端从每个接口的PULL队列发出PULL数据包,调整发包速率(pacing),以便它们从发送端引出的数据包到达/满足接收端的链路速率。默认情况下,来自不同连接的Pull数据包是公平的,或者在流具有更高优先级时具有严格的优先级。

  • 当拉数据包到达发送方时,发送方将发送与拉入计数器增量相同数量的数据包。排队等待重新传输的任何数据包都将首先发送,然后再发送新数据。

  • 当发送方发送的数据用完时,它会标记最后一个数据包。

当最后一个数据包到达时,接收端从其拉队列中删除该发送方的所有拉数据包,以避免发送不必要的拉数据包。发送方以后想要发送的任何后续数据都将被推送pushed而不是拉送pulled

由于包修剪,一个包实际上发生被丢包是非常罕见的;通常这是由于崩溃(设备)。由于ACKNACK是立即发送的,并且是优先转发的,而且所有交换机队列都很小,因此发送方可以很快知道数据包是否真的丢失了。使用8个分组交换队列、9KB的巨型以及10Gb/s胖树拓扑中的存储和转发交换机,每个分组需要7.2us来序列化。考虑到NDP的优先级排队,最坏情况下的网络RTT约为400us,典型的RTT要短得多。这允许使用非常短的重新传输超时来为这种损坏的数据包提供可靠性。

PULL数据包的作用类似于TCPACKACK-clock,但通常与ACK分开,以便在不影响重传超时机制的情况下调整它们的速度。例如,在大型incast场景中,在pacer调节器允许发送拉取之前,拉取可能在接收端的拉取队列中花费相对较长的时间,但是我们不希望也延迟ACK,因为这样做需要对重传超时更加保守。

紧急行为是推送连接中的第一个RTT数据,然后拉取随后RTT的数据,以达到接收端的线速率。在incast场景中,如果多个发送方同时发送,那么它们的许多第一个数据包窗口将被修剪,但是随后的接收端使用拉取确保来自所有发送方的总到达率与接收端的链路速度匹配,这样就很少或没有数据包被修剪。

3.2.1 应对重新排序


由于逐包多路径转发,数据包和反向路径ACKNACKPULL数据包需要重新排序是正常的。基本协议设计对重排序具有鲁棒性,因为它不需要从其他数据包的序列号推断丢包。然而,重新排序仍然需要加以考虑。

尽管PULL包是优先级排队的,但它们不会抢占数据包,因此在不同路径上发送的PULL包通常会无序到达,从而增加重传的突发性。为了减少这种情况,PULL携带一个pull序列号。接收端对每个连接都有一个单独的拉序列空间,对每个发送的拉序列空间递增处理。在接收到请求时,发送方发送的数据包数量与请求序列号增加的数量相同。例如,如果一个PULL被延迟,那么发送的下一个PULL可能首先通过不同的路径到达,并且将拉两个包而不是一个包。这会减少一点突发性。

3.2.2 第一RTT


TCP中的SYN/SYN-ACK握手发生在数据交换之前不同,我们希望NDP数据在第一个RTT中发送。这增加了三个新要求:

 对伪造源IP地址的请求具有鲁棒性。

 确保连接不会被意外处理两次。

T/TCPTCP Fast Open都扩展了TCP以在第一个RTT中发送数据。TFO通过在以前的连接中提供服务器给定的令牌来防止欺骗,但不能确保at-most-once语义。T/TCP使用单调递增的连接ID可实现最多一次at-most-once语义,但它对欺骗并不鲁棒。如果SYN不是第一个到达的包,那么这两个包都不能很好地处理。

NDP的要求略有不同。可以在虚拟机监控程序或NIC中防止欺骗,或者将VXLAN用于多租户数据中心,因此这不是一个大问题。尽管语义有时是至关重要的,但T/TCP的解决方案对背背短连接之间的多路径重新排序并不健壮。NDP通过在客户机和服务器上都保持time wait状态来解决这个问题,因此两者都可以拒绝重复的连接。由于最大段生存时间小于1ms,额外状态的数量相当少。

最后,在第一个RTT中可以发送多个包,但是第一个到达的包通常不是第一个发送的包。为了鲁棒性,第一RTT中的每个分组携带SYN标志,同时携带其序列号与连接中的第一个分组的偏移量。这允许连接状态由最先到达的包建立。

3.2.3 鲁棒性优化


如果网络运行正常,则上述协议的性能非常好。但是,有时链路或交换机会发生故障。这通常是由路由协议检测到的,然后故障被路由到周边(传播)NDP包是源路由的,因此NDP主机还需要接收这些路由更新,以知道要避免哪些路径。然而,在路由协议通知所有人之前,到达失败链路的数据包将丢失。其他更微妙的故障也可能发生,例如10Gb/s链路决定协商到1Gb/s,从而导致路由无法立即检测到热点。以前的工作表明,在这些情况下,使用单路径拥塞控制(例如TCP)和网络数据包散列(packet-spraying会导致性能严重降低,因为传输协议没有意识到只有一条路径行为不正常。

在这种情况下,NDP包含了可以大大提高性能的优化。发送方保留一个路径记分板,发送方跟踪每个数据包经过的路径。当ACKNACK到达时,发送数据包的路径的ACKNACK计数递增。通常,在运行NDPCLOS拓扑中,所有路径的ACKNACK的比率应该非常相似。然而,如果一个失败已经导致不对称,一些链接将有过多的NACK计数。当发送方排列路径列表时,它会临时从路径集中删除异常值。

数据包丢失几乎永远不会发生。重新传输丢失数据包的NDP发送方总是在不同的路径上重新发送它。每次数据包丢失时,路径丢包计数器也会递增。任何与数据包丢失有关的异常路径也会从路径集中临时删除。

这些机制允许NDP对路径不再具有类似性能的网络具有健壮性,无论出于何种原因,性能损失最小。传统的基于逐流ECMP多路径转发的协议很难处理此类故障,并且依赖路由来检测和避免坏路径。

3.2.4 返回发送方


包修剪可以处理大的incast而不需要丢弃任何报文头。但是,非常大的incast可能会使报头队列溢出,导致丢包。当发送方的RTO过期时,丢失的数据包将被迅速重新发送。由于小队列确保了400us的最大RTT,最大RTO可以安全地低至1ms。在incast期间,Tor交换机队列可以在溢出之前保存89KB数据包和(在相同内存量中)112564字节的报头。接收端将拉1125个包的重传数据包,调整它们到达的速度以保持其链路饱和。在10Gb/s时,11259KB的数据包将占用接收端的链路8ms,因此任何由于RTO而重新发送的数据包仍然可以到达在链路空闲之前溢出的队列。

然而,有时整个传输将适配(fit)单个分组,并且该传输可能具有高优先级,例如,它可能是来自先前请求的滞后数据包。如果这样的数据包丢失,依赖RTO会增加不必要的延迟。作为优化,当报头队列溢出时,交换机可以交换发送方和接收端的地址,并将报头返回给发送方。然后发送方可以重新发送有问题的数据包。但是,总是重新发送可能会导致原始incast响应数据包NDP只有在不期望更多的拉取时才重新发送,即没有已确认或已确认但尚未拉取的数据包,或者第一个窗口的所有其他数据包也已返回。这避免了不快的响应,但保持了时钟的运行。如果大多数数据包最近被确认而不是被NACKedNDP也会重新发送。这表示一个不对称的网络,在不同的工作路径上重新发送是有意义的。

返回发送方(Return-to-sender是一种优化;根据我们的经验,它只适用于非常大的incast场景。在CLOS拓扑中,它本质上使得NDP对于元数据是无损的;RTO仅在数据包损坏或出现故障时触发。

4显示了432节点Fat-Tree仿真结果,该仿真演示了这些机制的作用,给出了从第一次发送数据包到在发送方确认数据包的延迟CDF,包括由于重新传输而产生的任何延迟。排列曲线显示了每台主机何时从另一台主机发送和接收数据,以及随机显示了每台主机何时向随机主机发送数据——在这两种情况下,这些数据都会完全加载Fat-Tree,但平均延迟保持在100us左右。Incast曲线显示了当100个节点同时发送到单个节点时发生的情况;它们在传输的大小上不同。所有节点在第一个RTT中发送整个文件135KB;这不仅会导致高修剪率,而且会使报文队列溢出,只有25%报文头被返回给发送方。尽管如此,最后一个数据包的到达时间为11055us,仅比理论上的最佳到达时间晚2%。对于1350KB大小的文件,第一个数据窗口所用的时间与135KB传输所用的时间相同,但传输的其余部分进行得很顺利,没有微调,平均延迟为95us

拥塞控制

精明的读者现在可能想知道NDP对拥塞控制有什么作用。答案很简单:在CLOS拓扑中,NDP不执行任何拥塞控制。正如我们将要展示的,如果将网络服务模型和传输协议正确地结合起来,拥塞控制是完全没有必要的。从广义上讲,网络拥塞控制有两个作用:一是避免拥塞崩溃,二是保证公平性。NDP在没有显式窗口自适应机制的情况下实现了两者。

避免拥塞崩溃。正如我们在第2.3节中看到的,NDP交换机通过确保数据包使用大部分链路来避免CP的拥塞崩溃。如果数据包在接收端处被丢弃,也可能发生崩溃,如预Jacobson重传超时pre-Jacobson retransmission timeout或碎片fragmentation。由于包修剪,NDP发送方很少需要依赖RTO,因此不可能由于不必要的重传而崩溃。

如果在接收端附近丢弃了大量数据包,而接收端之前已经替换了路径上的其他数据包,则可能会发生崩溃。然而,在具有NDP逐包多路径路由的CLOS拓扑中,由于不可能将业务集中在核心交换机的上行链路上,数据包几乎从不被修剪。

当它们在上行链路上被修剪时,这是由于不完美的负载平衡造成的;这就是NDP基于源的负载平衡在交换机执行的逐包随机ECMP上提供优势的地方。即使在高负载下,这里修剪的数据包也只占总流量的很小一部分,例如,在运行全排列流量矩阵的128节点Fat-Tree仿真中,每个节点从一个节点接收数据,并以10Gb/s的链路速度发送到另一个节点,当执行源负载平衡时,我们看到上行链路上修剪的数据包占0.01%相比于交换机执行负载平衡时此值2.4%

只有在inccast期间才真正发生显著的修剪,大多数数据包在从ToR交换机到主机的链路上被修剪,少数数据包在上ToR交换机和下ToR交换机之间被修剪。因此,被ToR交换机修剪的数据包在拓扑结构的早期很少替换数据包。

公平NDP在不需要额外机制的情况下实现了很好的公平性。所有相互竞争的流都从同一个窗口开始,因此不必担心收敛性。流竞争的主要点是为接收者提供容量,接收者对正在发生的事情有一个完整的视图。接收公平性是通过对拉队列中属于不同连接的数据包使用公平队列方案来实现的。最后,故意的不公平是可能的,因为接收者知道自己的优先级,并且可以比低优先级流量更频繁地拉高优先级流量。

不公平的一种情况是不能被接收端管理,即一个接收端的流与同一个ToR交换机上另一个接收端的流竞争。NDP减轻了RTT中的这种不公平,因为在那之后,接收端PULL的调速消除了过载。

NDP的局限性

我们实验评估表明,在完全配置的多层CLOS拓扑fully-provisioned folded CLOS topologies中,NDP非常接近最优,甚至讨论了NDP在此类网络之外的局限性。

在诸如BCubeJellyish这样的非对称拓扑中,NDP的性能很差,因为它会将数据包分散在不同长度的路径上,当网络负载很重时,使用这些路径的成本很高。对于这样的网络,基于发送方的路径多路径拥塞控制已经被证明是有效的;如何将每条路径的拥塞控制与基于pull接收端驱动协议协调起来仍然是一个悬而未决的问题。

拥塞控制在核心交换机持续拥塞的严重超额订阅网络上也是可取的,因为NDP的激进设计将导致即使在第一次RTT之后也会进行连续的包修剪。我们在评估中表明,在这种情况下,NDP仍然比DCTCP提供更好的性能,但某种形式的拥塞控制将有助于减少服务器重传负载。

最后一个问题与部署有关:当P4交换机广泛部署在数据中心时,运行NDP就像部署交换机实现和终端系统堆栈一样简单。

然而,NDP可能会将竞争的TCP流量拒之门外。然而,通过从不同的队列中服务NDPTCP,确保它们之间的公平队列,可以很简单地确保与TCP共存。TCP队列将更大(100个数据包),而NDP将更小(8个数据包),再加上一个大小相似的报头队列。



结论



本文提出了一种新的数据中心网络体系结构NDP,它包括一种改进的交换队列算法和逐包多路径转发,以及一种利用这些网络机制的新型传输协议。无论是在我们的实现中,还是在大规模的仿真中,NDP都表现出良好的低延迟行为。与依赖无损以太网实现低延迟的DCQCN等机制相比,它在不同工作负载之间提供了更好的隔离。

就终端系统所需的CPU资源而言,我们当前的实现相当昂贵,因为需要精确的拉取速度和低延迟的重传。这两种功能对于以太网NIC来说都非常简单;实际上,廉价的WiFi网卡已经能够处理重传和谨慎的数据包计时。如果NDP能够大规模部署,我们期望智能NIC能够大大降低NDPCPU开销。


参考文献

M. Handley, C. Raiciu, A. Agache, A. Voinescu, A. W. Moore, G. Antichik, and M. Mojcik. Re-architecting Datacenter Networks and Stacks for Low Latency and High Performance. In Proceedings of the ACM SIGCOMM 2017 Conference, SIGCOMM ’17, pages 29–42, New York, NY, USA, 2017. ACM.







扫码二维码
关注我们
了解更多精彩





END



文章转载自网络技术风云汇,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论