当前位置：首页 > ICNP > 正文

【ICNP 2019】GEMINI：跨数据中心网络的拥塞控制

ICNP
2022-10-18
1745
更新：2023-01-04 21:47:04

> 原文题目：Congestion Control for Cross-Datacenter Networks.
> 作者：[香港科技大学 陈凯](https://cse.hkust.edu.hk/~kaichen/) 等

# 摘要

地理上分布的云端应用程序正变得越来越普遍。它们运行在由广域网(WAN)连接的多个数据中心网络(DCN)组成的跨数据中心网络上。由于DCN和WAN具有截然不同的特性(例如，缓冲区深度、RTT)，因此这种跨DC网络在传输设计方面带来了重大挑战。

在本文中，我们发现仅对ECN或延迟作出反应的现有DCN或WAN传输方式无法(也无法扩展到)在这种环境下正常工作。关键原因是，这两个信号本身都不能同时捕获拥塞的位置和程度。这是因为DCN和WAN之间存在差异。基于此，我们提出了GEMINI的设计和实现方案，该方案战略性地集成了ECN和延迟信号，用于跨DC拥塞控制。为了实现低延迟，GEMINI使用延迟信号限制DC间延迟，并使用ECN防止DC内丢包。为了保持高吞吐量，GEMINI利用拥塞信号动态调节窗口并保持低缓冲区占用率。GEMINI是在Linux内核中实现的，并通过大量的测试台实验进行了评估。结果表明，与TCP Cubic、DCTCP和BBR相比，GEMINI实现了53%、31%和76%的小流量平均完成时间的减少程度；与TCP Vegas相比，大流量平均完成时间减少了58%。

# 1、引言

在地理是分布的环境中运行的应用程序越来越普遍。大型在线服务通常将其数据共享或复制到不同地理区域的多个DC中。例如，零售商网站运行在每个区域数据中心复制的库存商品数据库，以快速服务本地客户。这些区域数据库定期相互同步以获取最新数据。其他例子包括在线社交网络上的图像共享、视频存储和流媒体、地理分布数据分析等。

这些应用程序运行在由广域网(WAN)连接的多个数据中心网络(DCN)组成的跨数据中心(DC)网络(图1)上。广域和DC内部网络具有截然不同的特征(第2.1节)。对于广域网来说，实现高网络利用率是重点，交换机具有深缓冲区。相反，延迟在DCN中非常关键，交换机具有浅缓冲区。虽然有许多传输协议分别为DCN或WAN设计，但据我们所知，很少有工作考虑同时包含这两部分的跨DC环境。

为了在DCN或WAN中处理拥塞控制，现有的解决方案利用ECN(如DCTCP和DCQCN)或延迟(如Vegas]和TIMELY)作为拥塞信号，并成功地在高吞吐量和低延迟方面提供了令人信服的性能。不幸的是，由于DCN和WAN之间的差异，为DCN或WAN设计的现有解决方案都不能很好地适用于跨DC网络(第2.2节)。更糟糕的是，即使不是不可能，它们也不太可能很容易地扩展并很好地工作。

根本原因是，这些解决方案仅利用其中一个信号(ECN或延迟)，这足以满足相对单一的环境。然而，就其性质而言，ECN或延迟本身无法处理异构性。首先，ECN很难配置以满足混合流的要求。跨DC和DC内的流量在跨DC网络中共存，RTT变化高达1000x。较小的RTT流需要较低的ECN阈值以实现低延迟；而大RTT流需要更大的ECN阈值才能实现高吞吐量。事实上，调整ECN阈值可能不起作用，因为DC交换机浅缓冲区很容易被突发的具有较大BDP的跨DC流量淹没。例如在实际工作负载下的实验中，DCN可以比广域网多4~20x数量的数据包丢失。

同时，延迟信号本身限制了同时检测广域网和DCN中的拥塞。跨DC流可能在WAN或DCN中拥塞，而延迟信号由于其端到端的性质而无法区分它们。这导致了一个两难境地，要么是延迟阈值较小的WAN(深度缓冲)导致的链路利用不足，要么是阈值较高的DCN(浅缓冲)数据包丢包率增加。例如，Vegas在将其默认参数扩展20倍时，以大于30倍的DC内数据包丢失为代价实现了1.5倍的更高吞吐量。此外，低延迟阈值对精确延迟测量提出了苛刻要求，需要额外的硬件支持。

上述问题要求在跨DC网络通信的拥塞控制中，不能仅考虑其中之一，而要同时考虑ECN和延迟信号。具体地说，新的解决方案必须能够处理以下关键挑战(第3.1节)，这些挑战没有暴露于任何以前的工作中：(1)如何在异构环境中实现持久的低延迟，即使DC交换机(更有可能丢弃数据包)和WAN路由器(更有可能积累大量缓冲)有着截然不同的缓冲深度。(2) 如何使用浅缓冲DC交换机保持DC间通信的高吞吐量，即使传播延迟在几十毫秒范围内，而不是DCTCP等DCN传输协议假定的<250us。

为此，本文提出GEMINI通过以下三个主要思想(第3.2节)将ECN和delay有机地结合起来，以应对上述两个挑战：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">**集成ECN和延迟信号，用于拥塞检测**。延迟信号用于限制整个网络路径(包括WAN段)上的总飞行流量，而ECN信号用于控制DCN内的每跳队列。通过有限的端到端延迟和有限的数据包丢失，可以保证持久的低延迟。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">**通过流的RTT调节ECN触发的窗口减少攻击性**。与传统的TCP不同的是，对于较大的RTT流，传统的TCP会更多地消耗队列，我们会使较大的RTT流降低速率，从而产生更平滑的“锯齿”窗口动态。这反过来又防止了DC间流量利用率不足的带宽，同时维持了DC内流量的低ECN阈值。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;"> **适应窗口增加中的RTT变化**。我们按照RTT比例调整加性窗口增加步长，从而更好地平衡了混合DC间和DC内流量下的收敛速度和系统稳定性。
</span>

最后，我们通过广泛的试验台实验来评估GEMINI(第4节)。我们使用Linux内核4.9.25和商品交换机实现GEMINI。我们表明，与DCN拥塞下的DCTCP相比，GEMINI提高了49%的吞吐量，与WAN拥塞下的Cubic相比，RTT降低了高达87%；不考虑RTT的不同，快速稳定地收敛到带宽公平共享点；并与Cubic、DCTCP和BBR相比提供低流量完成时间(FCT)，小流量平均FCT分别减少53%、31%和76%；与Vegas相比，大流量平均FCT降低了58%。

# 2、背景和动机

我们在第2.1节中展示了跨DC网络的异质性，并在第2.2节中展示了传输性能损伤。

## 2.1 跨DCN中的异质性

现实世界中的跨数据中心网络在以下方面呈现异构特征：

**异构网络设备**。跨DC网络由来自内部DC网络(DCN)和跨DC WAN的异构网络设备(例如，具有不同的缓冲区深度)组成。表一给出了DCN和WAN中常用的交换机或路由器的概况。DCN交换机具有浅缓冲区，每个端口每Gbps的缓冲区高达数十KB。相比之下，广域网路由器采用深度缓冲区，每端口每Gbps高达数十兆字节。

**DC内和DC间流量混合**。DC内和DC间流量在跨DC网络中共存。它们表现出非常不同的RTT。为了证明这一点，我们在全球12个具有代表性的DC的一个主要云平台上进行RTT测量。图2显示了结果。DC内部RTT小到数百微秒。相反，DC间RTT从几毫秒到数百毫秒不等。

**不同的控制权限**。云运营商完全控制DCN，但并不总是控制WAN设备。这是因为许多云运营商从互联网服务提供商(ISP)租赁网络资源(例如，保证带宽)，而广域网设备由ISP维护。因此，某些交换机功能(例如ECN)可能在WAN中得不到很好的支持(禁用或配置了不需要的标记阈值)。

异质性给传输设计带来了巨大的挑战。理想情况下，传输协议应考虑拥塞位置(缓冲区深度)、流量类型(RTT)和支持的机制(如ECN)。在不考虑以下小节(第2.2节)中的异质性的情况下，我们展示了先前的设计是如何受到影响的。

## 2.2 异质性下单一信号的限制

大多数现有传输协议使用ECN或延迟作为拥塞信号。虽然它们在DCN或WAN中都可以很好地工作，但我们发现ECN或延迟本身无法处理异构性。我们进行了大量的实验来研究在跨DC网络中单独利用ECN或延迟信号时对性能的影响。

测试台：我们构建了一个测试台(图3)，它模拟了由DC间WAN链路连接的2个DC。每个DC有1个边界路由器、2个DC交换机和24台服务器。所有链路的容量均为1 Gbps。DC内和DC间基本RTT(无排队)分别为~200us和~10ms。DC交换机和边界路由器的最大每端口缓冲区大小分别为450和10000个1.5 KB MTU大小的数据包。

**实验方案**：我们实验了Cubic、Vegas[11]、BBR和DCTCP。Cubic在有无ECN的情况下进行了试验。DC交换机的ECN阈值设置为300个数据包，以保证DC间通信的高吞吐量。在WAN段中未启用ECN。Vegas使用两个参数alpha和beta来控制飞行中过量数据包的上下限。我们对默认设置(alpha=2；beta=4)进行实验，并按10倍设置(alpha=20；beta=40)进行缩放。

我们根据web搜索的产品跟踪运行实际工作负载。所有流都穿过DC间WAN链路。DC间和DC内链路的平均利用率为~90%及~11.25–45%。流量完成时间(FCT)结果如图4所示。我们提出以下意见和主张，并在本节稍后部分详细阐述：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">仅基于丢包或ECN信号的传输(例如Cubic、Cubic+ECN和DCTCP)在小流量FCT中表现不佳(图4(a)和4(b))。这是因为它们在浅缓冲DCN(表II)中经历了高数据包丢失，在WAN中没有ECN的情况下经历了大排队延迟。我们进一步发现，在混合流量下，配置ECN阈值从根本上说是困难的。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">基于延迟信号的传输，当使用小阈值(例如，Vegas)时，可实现小流量的良好性能(图4(a)和4(b))，但代价是减慢大流量(图4(c))。相反，当使用大阈值时(例如，按10倍参数缩放的Vegas)，它们会大大降低小流量的性能。我们进一步论证了在不同的缓冲区深度下设置延迟阈值的困境。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">BBR遭受高丢包率(>0.1%)，导致小流量FCT较差(图4(a)和4(b))。BBR需要精确估计可用带宽和RTT，这在动态工作负载下很难实现。
</span>

**只有ECN信号解决方案的问题**。基于ECN的传输使用反映每跳网络拥塞的ECN信号。为了提供高吞吐量，ECN标记阈值必须与带宽延迟乘积(BDP)成比例设置。然而，在跨DC设置中，由于RTT的巨大差异以及DC内和DC间流施加的不同要求，很难进行配置。DC内部流施加较小的缓冲压力，但具有严格的延迟要求(例如，数百微秒)。相比之下，考虑到广域网的较大基本延迟，DC间流的延迟要求更为宽松，相反，需要较大的缓冲空间以实现广域网的高利用率。

为了演示这个问题，我们使用DCTCP生成从同一机架中的主机到远程服务器的incast流。我们在这个环境中进行了两个实验。在第一个实验中，我们在同一个DC中选择了一个目标服务器，因此只存在DC内流。在第二个实验中，我们在远程DC中选择了一个目标服务器，因此只有DC间流。在这两种情况下，由于incast流量模式，瓶颈链路位于源DC交换机处。我们将瓶颈交换机的ECN标记阈值更改为每个端口20、40、80、160和320个数据包。

图5(a)和图5(b)分别显示了DC内和DC间流的吞吐量和延迟结果。从图5(a)中，我们观察到需要一个小的阈值来实现DC内流的低延迟。相比之下，从图5(b)中，我们观察到DC间流需要一个高阈值来实现高吞吐量。显然，存在一个冲突：在跨DC网络中，DC间和DC内流不能同时实现高吞吐量和低延迟。

事实上，在跨DC上实现高利用率并不重要，因为DC内交换机具有浅缓冲区-浅缓冲区很容易被突发的大型BDP跨DC流(我们称之为缓冲区不匹配)淹没。我们通过在以前的动态负载实验中测量数据包丢失率(PLR)来证实这一点。表二显示了结果。我们发现数据包丢失主要发生在DCN内(>80%)，即使DC间WAN的负载比DC内链路更重。高丢包会导致丢包敏感协议的低吞吐量。大的BDP跨DC流量是问题的关键因素。我们重复相同的实验，将跨DC链路延迟设置为0。所有流量现在都是低BDP。这一次，我们观察到所有基于ECN的方案的DCN内的小PLR($$<10\times10^{-5}$$)。此外，我们发现像在BBR中那样简单地调整数据包的速度并不能完全解决这个问题。例如，在DCN中具有FQ/pacing的Cubic与原始Cubic相比具有类似的高PLR($$66\times10^{-51}$$)。

此外，基于ECN的传输需要来自所有网络交换机的ECN标记支持。然而，在广域网中可能无法很好地支持ECN标记。因此，基于ECN的传输可能会重新使用丢包信号，导致高丢包率和长排队延迟。

**只有延迟信号解决方案的问题**。基于延迟的传输使用反映累积的端到端网络延迟的延迟信号。通常，它们有一个阈值来控制飞行中的总流量。然而，考虑到WAN和DCN中不同的缓冲区深度，在设置延迟阈值时会出现一个两难的问题——会牺牲DC间吞吐量或DC内延迟。

跨DC流可能在WAN或DCN中面临拥塞。鉴于延迟信号的端到端特性，它对这两种信号的处理是不可区分的。一方面，如果我们假设广域网发生拥塞，延迟阈值应该足够大(通常与BDP成比例)，以充分利用广域网带宽。但是，如果瓶颈位于DCN中，则较大的阈值(例如，10 ms×1 Gbps=1.25 MB)很容易超过DC交换机浅缓冲区(例如，83 KB/Gbps)，并导致频繁的数据包丢失。另一方面，如果我们假设在DCN中发生拥塞，则延迟阈值应足够低(至少受DC交换机缓冲区大小的限制)，以避免严重的DC内数据包丢失。然而，如果瓶颈位于广域网中，低阈值会极大地降低带宽利用率。总之，设置延迟阈值的难题出现了。

为了演示这个问题，我们运行本节前面使用的相同基准工作负载。我们使用默认设置(alpha=2；beta=4)对Vegas进行实验，并按N倍设置(alpha=2×N；beta=4×N)进行缩放，其中N被设置为1、5、10、15、20。结果如图6所示。一方面，较小的延迟阈值会降低DC间吞吐量，从而导致大流量的高平均FCT。另一方面，在浅缓冲DCN中，大延迟阈值显著增加了数据包丢失。因此，设置延迟阈值面临着要么损害DC间吞吐量，要么降低DC内丢包率的困境。此外，低延迟阈值对准确的延迟测量提出了苛刻的要求，为此需要额外的设备支持(如NIC发送ACK)。

# 3、GEMINI

我们在第3.1节中介绍了我们的设计原理，在第3.2节中描述了详细的GEMINI拥塞控制算法，并在第3.3节和第3.4节中提供了理论分析。

## 3.1 设计原理

**如何在异构网络环境中实现持久的低延迟？**持续低延迟意味着低端到端排队延迟和接近零的数据包丢失。显然，ECN作为每跳信号，不是限制端到端延迟的好选择；更不用说，ECN在广域网中的可用性有限。如果我们单独使用延迟信号，考虑到DC交换机浅缓冲区，小延迟阈值对于低丢包是必要的。但是，由于飞行流量较小，我们可能无法填充WAN段的网络管道(如第2.2节所示)。

我们没有单独使用单一类型的信号，而是集成了ECN和延迟信号来应对这一挑战。特别是，鉴于延迟信号的端到端性质，它被有效地用于限制飞行中的总流量；ECN信号作为每跳信号，用于控制每跳队列。在DC交换机处执行积极的ECN标记，以防止浅缓冲区溢出。因此，消除了使用小延迟阈值的限制，为提高WAN利用率留下了更多空间。通过这种方式，上述基于延迟的传输的困境自然得到解决。

**如何使用浅缓冲DC交换机保持DC间通信的高吞吐量？**大多数传输协议(如DCTCP)遵循加性增加乘性减少(AIMD)拥塞控制规则。它们在每个窗口缩减中消耗的队列长度与BDP(C\times RTT)成比例。本质上，每次排出的队列长度应小于交换机缓冲区大小，以避免缓冲区变空并保持完满吞吐量。因此，鉴于跨DC网络中的RTT范围较大，需要高缓冲区。在深度缓冲广域网中，设置适度高的延迟阈值可以很好地平衡吞吐量和延迟。然而，在浅缓冲DCN中，为了降低排队和丢失率，需要积极的ECN标记。由于缓冲区空间有限，维持高吞吐量变得极其困难(见第2.2节)。

为了解决这个缓冲区不匹配的挑战，我们通过RTT调节ECN触发的窗口缩减的攻击性。实际上，保持高吞吐量需要大的RTT流来排空队列，就像窗口缩减期间小的RTT流一样。直观地说，我们使较大的RTT流更温和地降低速率，从而产生更平滑的“锯齿”窗口和队列长度动态。通过这种方式，可以有效地降低利用率不足的带宽，同时仍然使用较小的ECN标记阈值。使用较小的ECN阈值在浅层缓冲区交换机中留下足够的空间，因为它保持了平均缓冲区占用率较低，减少了延迟和数据包丢失。

## 3.2 GEMINI算法

GEMINI是一种基于窗口的拥塞控制算法，它使用加性增加和乘性减少(AIMD)。根据上述设计原理，GEMINI利用ECN和延迟信号进行拥塞检测。

它进一步调整窗口缩小的程度以及基于流的RTT的增长函数，以兼容异质性。图7中的流程图和算法1中的伪代码总结了GEMINI算法。表三总结了参数和变量。

**集成ECN和延迟进行拥塞检测**。拥塞检测机制利用ECN和延迟信号。延迟信号用于限制网络管道中的飞行总流量。ECN信号用于控制DCN内的每跳队列。通过集成ECN和延迟信号，可以实现低延迟。具体而言，DCN拥塞由ECN检测，以满足浅层缓冲区施加的严格的每跳排队控制要求。广域网拥塞是通过延迟来检测的，因为端到端延迟主要在广域网中，而不是在DCN中。

DCN拥塞由ECN信号指示——发送方接收的ACK中设置的ECN-Echo标志。ECN信号的生成与DCTCP完全相同。当瞬时排队超过DC交换机的标记阈值时，数据包被标记为经历拥塞(CE, Congestion Experienced)。然后，接收机通过带有ECN-Echo标志的ACK将ECN标记发送给发送方。给定浅缓冲DCN，ECN信号利用一个小的标记阈值来降低数据包丢失。WAN拥塞由延迟信号指示——数据发送后返回的ACK持续较大延迟：

$$RTT_{min}>RRTT_{base}+T$$，其中$$RTT_{min}$$是在先前RTT(窗口)中观察到的最小RTT；$$RRTT_{base}$$，或简化为$$RTT$$，是基准RTT(长时间内观察到的最小RTT)；T是延迟阈值。我们使用$$RTT_{min}$$而不是平均或最大RTT，这可以更好地检测持续排队，并容忍可能由突发流量引起的瞬时排队。给定深度缓冲的WAN，延迟信号的使用具有较高的阈值，以实现高吞吐量和有限的端到端延迟。

当两个信号中的任何一个指示拥塞时，我们通过相应地减小拥塞窗口来响应该信号。当ECN和延迟信号都指示拥塞时，我们会对更严重的拥塞做出反应：

$$CWND = CWND \times (1-max(f_{DCN}, f_{WAN}))$$.

其中，$$f_{DCN}$$确定DCN中拥塞的窗口减少程度；$$f_{WAN}$$决定了广域网的拥塞窗口减少程度。我们将在本节后面介绍如何计算它们。

**通过RTT调节ECN触发的窗口减少攻击性**。窗口缩减算法的目的是在尽可能减少网络排队的同时，保持全带宽利用率。这本质上要求交换机缓冲区在瓶颈链路处永不下溢。给定不同的缓冲区深度，GEMINI针对DCN和WAN中的拥塞以不同的方式减少拥塞窗口。

在DCN中，给定浅缓冲区，使用严格的低ECN阈值来降低数据包丢失。我们采用了DCTCP算法，该算法在低ECN阈值下对DC内流工作良好。然而，对于大型RTT的DC间流，吞吐量会大幅下降。这是因为在窗口缩减期间由流排出的缓冲区随着其RTT的增加而增加(例如，DCTCP的队列大小振荡的幅度为$$O(\sqrt{C\times RTT}))$$。较大的RTT流更容易耗尽队列并占满交换机缓冲区，从而导致链路利用率较低。受此启发，GEMINI通过调制基于RTT的窗口缩减攻击性来扩展DCTCP。这指导了$$f_{DCN}$$的设计——即在DCN中检测到拥塞时窗口缩小的程度。当ECNs信号指示拥塞时，我们计算$$f_{DCN}$$如下：

$$f_{DCN} = \alpha \times F$$.

其中$$\alpha$$是ECN标记的数据包的指数加权移动平均(EWMA)分数，F是调节拥塞减少攻击性的因子。我们推导出比例因子$$F=\frac{4K}{ C\times RTT+K}$$(见定理1，在第3.3节中有详细证明)，其中C是带宽容量，RTT是长时间内观察到的最小RTT，K是ECN标记阈值。因此，对于DC内流，按照DCTCP中的准则，通过设置$$K=(C\times RTT)/7$$，我们得到F=12，与DCTCP算法完全匹配。对于具有更大RTT的DC间流，F变得更小，导致更小的窗口缩减和更平滑的队列长度振荡。

在广域网中，由于缓冲区要深得多，因此比在DCN中更容易保持高吞吐量。事实上，基于固定常数的窗口缩减，如标准TCP，足以实现高吞吐量。可有效使用的阈值设置范围很广(见第3.4节)。这指导了$$f_{WAN}$$的设计，即在WAN中检测到拥塞时窗口减少的程度。当RTT信号指示拥塞时，我们按如下方式计算f_{WAN}：

$$f_{WAN} = beta$$.

其中beta是WAN的窗口减少参数。

**适应RTT变化的窗口增加**。拥塞避免算法调整RTT(或带宽容量固定时的BDP)，以帮助平衡收敛速度和稳定性。对于常规AIMD，较大的BDP流需要更多的RTT来爬升到峰值速率，导致收敛缓慢；而较小的BDP流可能经常超出瓶颈带宽，导致性能不稳定。

根据BDP比例调整窗口增加步长，补偿RTT变化，使系统在异构情况下更具鲁棒性。此外，它还减轻了RTT的不公平性，这反过来有助于提高尾部性能。这导致自适应拥塞窗口增加因子h。当没有拥塞指示时，对于每个ACK

$$CWND=CWND+\frac{h}{CWND}$$

h是与BDP成比例的拥塞避免系数：$$h = H\times C \times RTT$$，其中h为常数，C为带宽容量，RTT为长时间内观察到的最小RTT。

## 3.3 比例因子F的推导

我们分析了GEMINI的稳态行为，证明了GEMINI在比例因子$$F=\frac{4K}{ C\times RTT+K}$$时实现了满吞吐量。

**定理1**：给定一个正的ECN标记阈值K，如果拥塞窗口减小如下，则在DCN拥塞下我们可以保持100%的吞吐量：

$$CWND=CWND\times (1-\alpha\times F)$$，

其中$$\alpha$$是ECN的EWMA比例，$$F\leq \frac{4K}{ C\times RTT+K}$$。

证明：与先前的工作相同，我们考虑N个具有相同往返时间RTT的长寿命流，共享容量的单一瓶颈链路C。为了便于分析，假设N个窗口大小是而同步的，队列长度：

$$Q(t)=N×W(t)-C\times RTT$$    （1）

其中$$W(t)$$是动态窗口大小。因此，队列大小过程也是锯齿形的。为了实现全链路利用率，我们需要保证：$$Q_{min}≥ 0$$(见图8)。

在源接收ECN反馈并相应减小其窗口大小之前，队列大小在每个周期中正好超过一个RTT的标记阈值K。我们可以通过简单地将循环最后一个RTT期间发送的数据包数量除以锯齿波整个循环期间发送的数据包总数来计算标记数据包的比例$$\alpha$$。

让我们考虑一个发送者。设$$S(W_1, W_2)$$表示发送方发送的数据包数量，而其窗口大小从$$W_1$$增加到$$W_2>W_1$$。因为这需要$$(W_2-W_1)/h$$往返时间，在此期间，平均窗口大小为$$(W_1+W_2)/2$$，

$$S(W_1, W_2)=(W_2^2- W_1^2)/2h$$                    (2)

让$$W∗= (C\times RTT+K)/N$$。这是队列大小达到K时的关键窗口大小，交换机开始使用拥塞经历(CE)标记数据包。在发送方作出反应之前的RTT期间，窗口大小在W+ H处达到峰值因此

$$\alpha=S(W, W+h) =S((W+h) (1-\alpha F), W+ h)$$                   (3)

将(2)代入(3)并重新排列，我们得到：

$$\alpha^2F(2 - \alpha F) = (2W+ h)h/(W+ h)^2\approx 2h/W$$                  (4).

其中，$$当W>> H$$.

方程(4)可用于计算$$\alpha$$作为网络参数C、RTT、N和K的函数。假设$$\alpha F$$较小，可简化为：

$$\alpha\approx\sqrt{ h/FW}$$ (5).

我们现在可以计算图8中的A，如下所示。请注意，单个流窗口大小的振幅D由以下公式给出：

$$D = (W+h) - (W+h)(1 - \alpha F) = (W+h)\alpha F$$ (6).

由于总共有N个流量，$$A=N\times D=N(W+h) \alpha F\approx N\sqrt{hFW} = \sqrt{NhF(C\times RTT+K)}$$ (7)

根据公式(1)，我们有：

$$Q_{max} = N \times (W+h) - C\times RTT = K + Nh$$ (8).

使用(7)和(8)，最小队列长度为：

$$Q_{min} = Q_{max} - A = K + Nh - \sqrt{NhF(C\times RTT + K)}$$ (9).

最后，为了找到比例因子F和ECN标记阈值K之间的关系，我们将(9)最小化，然后选择K和F，使该最小值不小于零(即队列从不下溢)。这导致：

$$F\leq \frac{4K}{ C\times RTT+K} $$ (10)

## 3.4 设置参数的指南

默认GEMINI参数设置如表四所示。除非另有规定，我们在所有实验中均采用默认参数设置。我们提供了以下设置参数的拇指规则，但将寻找最佳阈值设置留给未来的工作。

**ECN标记阈值(K)**。比例因子F确保给定ECN阈值(K)时的满链路利用率。由于较低的K表示队列较小，因此将K设置为尽可能低似乎是可取的。然而，这里实际上有一个权衡。当K很小时，缩放因子F也很小，使得流缓慢地减小其拥塞窗口，导致收敛较慢。因此，我们建议设置一个适度较小的阈值，即每Gbps 50个数据包。此外，为了减轻数据包突发的影响，我们在发送方使用每流量限制器来均匀地调整每个数据包的速度。

**排队延迟阈值(T)**。T应足够大，以在跨DC管道中实现高吞吐量。它还应该留出足够的空间来过滤来自DCN排队延迟的干扰。在实践中(第2.1节)，生产DCN中的RTT(包括排队)最多为1ms。我们建议将T设置为5 ms。

**窗口减小参数(beta)**。当检测到WAN拥塞时，GEMINI将窗口大小倍增$$\beta$$。为了避免带宽利用率不足，我们需要使排队净空$$T>\frac{\beta}{1-\beta RTT}$$，或理论上$$\beta<\frac{T}{T+RTT}$$。我们建议将$$\beta$$设置为0:2。我们表明，广泛的T和$$\beta$$设置可以很好地服务于第4节中的跨DC网络。

**窗口增加参数(H)**。GEMINI在没有拥塞的情况下，每RTT增加h个窗口。在我们的实现中，我们实际上用$$BDP(C\times RTT)$$而不是仅用RTT来缩放h，即$$h=H\times C\times RTT$$。这是合理的，因为较大的BDP意味着潜在的较大窗口大小。使用BDP缩放h可以更好地平衡收敛速度和稳定性。我们建议设置$$H=1.2×10^{-7}$$分别以0.1/5的有界最小/最大增加速度作为保护。

# 4、评估

在本节中，我们将在第4.1节中介绍详细的GEMINI Linux内核实现和评估设置，并进行大量实验以回答以下问题：

**第4.2节：GEMINI是否实现高吞吐量和低延迟？**我们发现GEMINI可以获得更高的吞吐量(1-1.5x)，与DCN拥塞下的DCTCP相比，具有同等低的延迟；在广域网拥塞情况下，与Cubic相比，延迟更低(>7×)，吞吐量也同样高。

**第4.3节：GEMINI收敛是否迅速、公平、稳定？**在静态流量实验中，我们发现，无论不同的RTT相差高达64倍，GEMINI在DCN拥塞和WAN拥塞情况下都能快速稳定地收敛到带宽公平共享点。

**第4.4节：GEMINI在实际工作量下表现如何？**在实际的流量实验中，我们发现在这两种情况下(DC内重流量或DC间重流量模式)，GEMINI在短流量和大流量情况下都能持续获得最佳或次最佳的流量完成时间。

## 4.1 实现和实验设置

**GEMINI实现**：GEMINI是基于Linux内核4.9.25开发的。Linux TCP堆栈有一个在struct tcp_congestion_op中定义的通用拥塞控制接口，它支持各种可插拔的拥塞控制模块。拥塞窗口缩减算法在in_ack_event()和ssthresh()中实现。拥塞避免算法在cong_avoid()中实现。

**试验台**：在两个试验台上进行试验，分别具有1Gbps和10Gbps的容量。1Gbps测试台比10Gbps测试台具有更大的规模。两个测试床共享相同的拓扑，如图3所示。有两个数据中心通过DC间WAN链路连接。每个数据中心有一个边界路由器、两个DC交换机和多个服务器。边界路由器由具有多个NIC的服务器模拟，因此我们可以使用NETEM来模拟WAN传播延迟。DC内(在单个ToR下)和DC间基本RTT分别为~ 200us和~ 10ms。DC交换机上的动态缓冲区分配与大多数运营商在实际部署中一样启用，以吸收突发数据。

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">大规模1Gbps测试台：有50台Dell PowerEdge R320服务器和4台Pica8 P-3297交换机。Pica8 P-3297交换机有48个端口共享的4MB缓冲区。WAN缓冲区设置为每个端口10000 MTU大小的数据包。所有网络接口均设置为1Gbps全双工模式。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">小型10Gbps测试台：华为RH1288 V2服务器10台，Mellanox SN2100交换机1台(分为多个VLAN)。Mellanox SN2100交换机有16个端口共享的16MB缓冲区。WAN缓冲区设置为每个端口80000 MTU大小的数据包。所有网络接口均设置为10Gbps全双工模式。
</span>

备注：默认情况下，我们显示大规模测试台的结果。

**比较方案**：我们实验了Cubic、Vegas、BBR、DCTCP和GEMINI。所有这些协议都在Linux内核中实现，并且易于部署。Cubic是Linux系统中使用的默认基于丢失的拥塞控制。在有无ECN的情况下进行了试验。

DCTCP是一种基于ECN的拥塞控制，旨在实现DCN中的高吞吐量、低延迟和高突发容忍度。ECN标记阈值设置为300个数据包，以保证DC间通信的高吞吐量。Vegas使用两个参数alpha和beta来控制飞行中过量数据包的上下限。我们对默认设置(alpha=2；beta=4)进行实验，并按10倍设置(alpha=20；beta=40)进行缩放，以显示吞吐量和延迟的权衡。BBR旨在基于准确的带宽和RTT探测，以最大的吞吐量和最小的延迟将拥塞控制推进到理论上的最佳点。GEMINI是本文提出的传输协议。如果没有指定，我们在本文的所有实验中都采用默认设置(表IV)。ECN标记在DCN中配置。

## 4.2 吞吐量和延迟

我们发现，GEMINI在DCN拥塞和WAN拥塞两种情况下都实现了高吞吐量和低延迟。

**处理DCN中的拥塞**。基于ECN的DCN拥塞控制模块需要处理DC交换机浅缓冲区和高BDP DC间流量之间的不匹配，以便在延迟和吞吐量之间取得良好的平衡。我们表明，通过添加BDP感知的比例因子F，可以在很大程度上缓解不匹配问题。

为了证明这一点，我们生成了共享一个DC交换机瓶颈链路的多对一长流。我们进行了两个实验，第一个实验中的所有DC内流和第二个实验中的所有DC间流。GEMINI在此禁用了基于RTT的WAN拥塞控制模块(即使我们启用该模块，该模块也不会工作，因为RTT阈值本身将过滤我们的DCN拥塞)。我们将ECN标记阈值K设置为20、40、80、160、320个数据包。

结果表明，对于DC内流动，GEMINI和DCTCP之间的差异很小。DC间流量的平均RTT也类似(因此此处忽略结果)。DC间流的吞吐量如图9所示。GEMINI将K设置为320个数据包时，吞吐量(938 mbps)略高于DCTCP(899 mbps)。设置更高的阈值是禁止的，因为只有有限的缓冲区可以避免突发流量下的数据包丢失。

**处理广域网的拥塞问题**。GEMINI利用延迟信号进行广域网拥塞控制。为了证明广域网中拥塞控制的有效性，我们在不同的T和beta设置下运行了广域网中共享一个瓶颈链路的多对一静态流。结果如图10所示。一般来说，GEMINI在排队延迟RTT不超过20 ms的情况下保持接近满吞吐量。与广域网中利用丢失信号的传输相比，GEMINI以更低的延迟为代价实现了类似的高吞吐量(例如，与排队延迟>100 ms的Cubic相比，延迟>7倍)。

**参数灵敏度**。GEMINI在广泛的参数设置下工作良好。为了实现低延迟，DCTCP建议为1 Gbps DCN将ECN标记阈值设置为低至20个数据包。对于较大的BDP DC间通信量(在我们的实验结果中，降低了70%)，此低ECN阈值显著地损害了DCTCP的吞吐量。事实上，当K设置为低于300个数据包时，DCTCP开始降低吞吐量。对于GEMINI，在阈值设置为100个数据包之前，吞吐量不会降低。更高的RTT导致更高的吞吐量，但代价是略高的RTT。较低的beta会导致更好的吞吐量，但会牺牲收敛速度。我们建议设置T=5ms，beta=0.2。在这种情况下，RTT比需要的稍高，为更高的RTT网络留出了更多的空间。实际上，这对于过滤掉DCN排队延迟(通常<1 ms)的干扰也是必要的。

## 4.3 收敛性、稳定性和公平性

为了评估GEMINI的收敛性和稳定性，我们首先从一台服务器启动一组10个流。50秒后，我们从同一机架中的另一台服务器启动第二组流。在100秒时，我们从同一DC中的另一个机架开始第三组流。所有流运行150秒，并在远程DC中共享同一个目标服务器。

图11显示了吞吐量动态(每个流组显示一个流)。考虑到其AIMD性质，GEMINI保证公平收敛。事实上，GEMINI在DCN拥塞(50-100秒)和WAN拥塞(100-200秒)下都能快速稳定地收敛。例如，在100-150秒内，GEMINI的平均Jain公平性指数为0.99，比其他协议好得多。

公平性对于良好的尾部性能非常重要。RTT不公平性是在跨DC网络中实现单流带宽公平共享的主要挑战，在跨DC网络中，不同RTT的DC内和DC间流量共存。我们证明了GEMINI通过因子h和比例因子F可以实现良好的RTT公平性。为了证明这一点，我们在DC内生成了共享相同瓶颈链路的4个DC间流和4个DC内流。DC内部RTT是~200微秒。在tc NETEM中，DC间RTT设置为DC内RTT的4倍、8倍、16倍、32倍、64倍。所有启用ECN的协议都采用相同的300个数据包的ECN阈值进行公平比较。实验结果如图12所示。虽然Cubic和DCTCP实现了比例RTT公平性，BBR向大的RTT流倾斜，但GEMINI保持了相同的带宽公平共享，而不管RTT如何变化。

## 4.4 实际工作流量

我们在实际工作负载下评估GEMINI。工作负载是根据在支持web搜索的数据中心中观察到的流量模式生成的。流量通过泊松过程到达。源和目标从配置的IP池中统一随机选择。工作负载是重尾的，大约有50%的小流量(大小<100 KB)，而80%的字节属于10%的大流量(大小>10 MB)。我们使用一个公共可用的流量生成器运行工作负载，该生成器已被其他工作使用。与之前的工作类似，我们使用流完成时间(FCT)作为主要性能指标。

**流量模式1：DC间传输，广域网高度拥挤**。在本实验中，所有流都穿过WAN段。DC间WAN链路的平均利用率为~90%.DC边界路由器非常拥挤，而DC内链路的利用率要低得多(~11.25–45%).

实验结果如图13和14所示：(1) 对于小流量FCT，GEMINI在平均和第99分位尾流方面均优于Cubic、DCTCP和BBR。Cubic和DCTCP在广域网中存在较大的排队延迟，而GEMINI则能很好地处理RTT信号的排队延迟。由于带宽和RTT的错误估计被高拥塞放大，BBR遭受了很大的损失。在损失率>20%(作为保护)之前，BBR不会对损失事件做出明确反应。这种设计选择有利于长期吞吐量，同时会影响短期延迟。(2) 对于大流量FCT，GEMINI的表现要比Vegas好得多。Vegas的默认参数设置非常保守(alpha=2；beta=4)，导致大流量的吞吐量很低。在Vegas-10中设置更大的阈值(alpha=20；beta=40)可以提高吞吐量，但会影响小流量的延迟。(3) 对于整体FCT，GEMINI在所有试验传输中表现最好。

**流量模式2：混合传输，广域网和DCN高度拥挤**。在本实验中，每个流的源和目的地在所有服务器中均匀随机选择。DC内和DC间流量在网络中共存。DC间WAN链路的平均利用率为~ 90%.从DC交换机到边界路由器的链路的平均利用率为~ 67.5%.

实验结果如图15和16所示：(1)对于小流量FCT，GEMINI在实验传输中表现最好。事实上，GEMINI的数据包丢失率一直很低($$<10×10^{-5}$$) 在这两种流量模式下。BBR再次遭受高损失(>0.1%)。(2) 对于大流量FCT，GEMINI的性能优于Cubic和Vegas。Vegas表现不佳，因为它无法同时控制WAN和DCN中的拥塞。GEMINI可以分别使用ECN和RTT信号识别DCN和WAN中的拥塞并作出不同的反应。(3) 对于整体FCT，GEMINI在所有试验传输中表现最好。

# 结论

随着地理分布应用的普及，跨DC通信变得越来越重要。我们调查了现有的传输协议，发现它们单独利用ECN或延迟信号，无法适应跨DC网络的异构性。基于此，我们设计了GEMINI，一种集成ECN和延迟信号的跨DC拥塞控制解决方案。GEMINI使用延迟信号端到端地限制飞行中的总流量，而ECN用于控制DCN内的每跳队列。我们使用Linux内核和商品交换机实现GEMINI。实验表明，在跨DC网络中，GEMINI实现了低延迟、高吞吐量、公平稳定的收敛，并且与各种传输协议(如Cubic、Vegas、DCTCP和BBR)相比，其FCT更低。

**参考文献**：Zeng, G., Bai, W., Chen, G., Chen, K., Han, D., Zhu, Y., & Cui, L. (2019). Congestion Control for Cross-Datacenter Networks. 2019 IEEE 27th International Conference on Network Protocols (ICNP), 1-12.

> <span style="font-style: italic;">声明：本文素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。由于本人水平有限，如有纰漏，请以参考文献文章为准。</span>

<font color=red>**欢迎扫码关注微信公众号“网络技术风云汇”，更快速接收更多网络技术咨询。**</font>