论文信息：
数据中心传输协议的共存
摘要 云数据中心的出现直接导致了数据中心TCP（DCTCP）等自定义传输协议的出现。这些协议通过考虑数据中心的独特网络和流量特性来提高云应用的性能。然而，这样的协议只能在新建部署的情况下进行评估，需要假定整个数据中心都使用相同的协议，这在实际中并不可行。在数据中心中，自定义传输协议与TCP共存，共享网1络资源。本文对DCTCP和TCP并存进行了全面的研究。我们评估了在不同的主动队列管理方案（AQM）（包括RED，DCTCP AQM和CHOKe）下的带宽共享属性。研究结果表明，在DCTCP AQM下，DCTCP可能导致TCP分配的流量不足。这个问题通过使用RED来减轻，但是不公平现象仍然存在，而且CHOKe的存在加剧了这种不公平。在本文中，我们证明了CHOKe的修改版本能通过更精确地处理主导流量而大大提高了公平性。
Ⅰ. 介绍
大规模数据中心的出现已经因为网络搜索，社交网络和广告系统等大规模在线服务以及亚马逊，谷歌和微软等云计算服务提供商的崛起，转变了计算格局[1]。这些数据中心具有独特的网络和流量特性，可以承载多种应用。在应用的多样化要求下，为数据中心设计定制的传输协议[2][3] [4] [5] [6]应运而生。 例如，数据中心TCP（DCTCP）的设计是为了满足软实时应用的需求，如网络搜索，广告和零售[2]等
这些协议在假定整个数据中心使用相同协议的新建部署场景下进行了评估。但是，这种情况并不总是可行的。首先，典型的数据中心同时托管多个应用程序，以实现资源使用的灵活性和高效性[1]，[3]。在某些应用程序（例如，网页搜索和社交网络等软实时应用程序）需要使用截止期限感知（[3]）或延迟最小化（[5]，[6]）传输协议时，其他应用程序 （例如，具有服务级别协议的多租户环境中的云服务或与之相关的SLA）可能需要公平共享的传输协议[2]。其次，使用新的传输协议需要软件和/或硬件的改变，并可能要求重写应用程序（[4]，[6]），但这有时候并不现实（例如，由于使用专有系统） （例如，由于对新建部署需要大量的数据中心停机时间，降低了数据中心的可用性）。
这导致定制的数据中心传输协议与现有的传输协议（如TCP）共存并共享网络资源的情况。然而，这种共享可能会造成某种协议的低吞吐量或者饥饿的情况。本文对这些场景进行了全面的研究，并研究了在几种主动队列管理（AQM）方案下DCTCP和TCP的共存性质。
我们的结果表明，由于DCTCPAQM基于瞬时队列长度的进行标记，以及和TCP相比使用了更小的补偿因子，它可能导致TCP流量的匮乏。随机早期检测（RED）[7]可以提高协议之间的公平性，但仍然存在着吞吐量的显著差异。考虑到CHOKe[8]，由于其标记政策对TCP非流占主导地位产生了负面影响，它反而降低了公平性。因此我们建议对CHOKe进行一个简单的改变，这可以提高主流的检测精度，并大大提高RED的公平性。
本文具有如下贡献：
* 在不同的AQM方案下，我们对DCTCP和TCP共存行为进行了严格的分析。 通过模型分析，我们研究了增加和减少参数以及AQM对协议性能的影响。
* 本文表明，虽然RED提高了公平性，但CHOKe实际上降低了它。我们建议对CHOKe进行修改，通过更准确地主导主流，提高性能。
* 本文提出根据平均流量完成时间（AFCT）和吞吐量评估典型数据中心特定流量模式下的DCTCP和TCP。
本文的其余部分安排如下。 本文第二部分描述了DCTCP，讨论了AQM方案。 在第三部分讨论协议共存问题，在第四部分和第五部分讨论目前的评估问题。有关的工作在第六部分讨论，第七部分是结束语。
Ⅱ DCTCP和AQM方案
本节描述DCTCP和评估DCTCP和TCP共存的AQM方案。
A. 数据中心TCP
DCTCP [2]旨在通过使用标记数据包的一小部分对拥塞程度做出反应的方法，达到数据中心环境中的低延迟和高吞吐量的目标。当拥塞率低时，它使用一个小的补偿因子。当拥塞增加时，它增加回退因子。DCTCP使用的最大退避因子是0.5。DCTCP用于确定退避因子的公式如下：
F代表上一个RTT中被标记包的比例，DCTCP使用α/2作为退避因子。
B. 主动队列管理算法
DCTCP AQM：DCTCPAQM通过使用ECN设置Congestion Experienced（CE）位，在队列长度超过某个阈值K时标记所有的数据包。 与RED不同，DCTCPAQM使用瞬时队列长度，这会导致更主动的标记。
RED：REDAQM根据平均队列长度qavg概率标记数据包。当qavg超过下限阈值时，它开始标记数据包。标记概率p线性增加，直到qavg超过最大值，达到：
代表最大标记概率。当大于时，RED百分百标记达到的数据包。
CHOKe：CHOKeAQM建立在RED的基础上，通过包含基于流分类的优先标记/丢弃数据包的机制实现功能。当超过时，CHOKe从队列中挑选一个随机数据包，并检查输入数据包是否与随机数据包具有相同的流。如果为true，则标记两个数据包。否则，它使用等式（2）计算的概率标记传入分组。如果超过，则标记数据包
Ⅲ. 协议共存
许多数据中心传输协议基于网络条件来调整TCP参数来实现高性能[2]，[3]，[5]，例如，DCTCP根据网络拥塞程度在[0.5，1]范围内调整退避因子；D2TCP[3]根据流程截止时间调整回退因子；L2DCT [5]通过逼近最短剩余处理时间（SRPT）调度规则来调整增加因子和回退因子以最小化完成时间。因此，与TCP竞争时，这些协议基于参数设置的差异将实现不同的吞吐量性能。
现存在几种模型，它们能在协议共存时，使用不同的加性增加乘法减少（AIMD）参数来表征协议的性能[9]，[10]。但是，它们假设协议都承担相同的分组丢弃/标记概率，这在实际中可能并不成立，因为分组丢弃/标记概率取决于在路由器上采用的AQM方案的选择。 除了参数的差异之外，AQM方案还会显着影响协议的性能。 事实上，在某些情况下，使用AQM可能会加剧不公平甚至导致其中一个协议饥饿。
我们在这项工作中的目标是分析几个常用的AQM对协议共存的影响。我们评估这些AQM如何能够实现公平的丢弃/标记，使得协议性能的差异仅仅是由于它们的AIMD参数的差异，而不是交换机处的排队动态。
A. 量化吞吐量差异
我们现在只分析由于DCTCP和TCP使用的不同AIMD参数而引起预期的吞吐量差异。
考虑有N个流的AIMD系统，其中每个流分别使用不同的AI和MD参数，即α1和β1，使用模型与[9]，[10]中的模型类似。所有流用i∈{1,2，...，n}标记，共享一个瓶颈链接。假设所有流具有等于T的同质RTT，并且在队列变满之后通知每个流需要一个RTT。假定流是同步的;，并处于数据中心环境中的典型场景中[1]。在上述假设的基础上，文献[9]中描述的AIMD源网络收敛到一个唯一的稳态点，其中θ是正常数，Wss是窗口大小，xp由下式给出：
由于所有流具有相同大小的RTT，因此使用不同的AIMD参数的两个流（一个DCTCP和另一个TCP）的吞吐量Tr之比由下式给出：
图1显示了当DCTCP的退避因子在[0,5,1]的范围内变化时的变化。当增加时，也增加。发生这种情况的原因是，退避减小，与TCP相比，DCTCP能够保持更大的窗口大小，从而实现更高的吞吐量。注意，当= 0.5时，为1，流获得相同的吞吐量。
Ⅳ. 具有不同AQMS的TCP和DCTCP
在本节中，我们评估DCTCP和TCP在共享瓶颈链接时的共存属性。我们考虑包括RED，DCTCPAQM和CHOKe在内的几个AQM，并将其与Drop-Tail队列进行比较。
仿真设置：我们选择NS2作为仿真平台，使用单根树型拓扑来进行评估。单根树型拓扑是数据中心常用的拓扑模型[2]，[11]，[12]。瓶颈链路容量设置为1Gbps，而其他所有链路的容量均为10 Gbps。一个源生成TCP流，而另一个生成DCTCP流。我们使用具有ECN能力的TCPNewReno，数据包大小设置为1500字节。往返传播延迟（RTT）设置为250μs，如之前的论文[2]所报告，导致带宽延迟乘积（BDP）为约22个分组。缓冲区大小设置为250个数据包[2]。为了消除RTT异质性的影响，DCTCP和TCP流都使用相同的RTT。流的开始时间是随机的，用来防止任何相位效应的影响。除非另有说明，每个实验重复十次，本文报告了这些结果的平均值。
指标：我们使用以下两个指标比较DCTCP和TCP的性能：
Ÿ公平性：设吞吐量比，其中和分别是DCTCP和TCP流实现的平均吞吐量。 注意= 1意味着两个协议达到相同的吞吐量。
Ÿ系统效率：设总吞吐量，它是所有流吞吐量的总和。
A. 使用Drop-Tail的TCP和DCTCP
当瓶颈路由器使用Drop-Tail队列时，我们首先考虑TCP和DCTCP的共存属性。在这种情况下，当到达的数据包发现队列已满时，数据包（TCP和/或DCTCP）将从队列尾部丢弃。因此，两种协议的退避机制都由分组丢弃来驱动，这导致DCTCP以与TCP相同的量退避，即0.5。在图2中可看出，两个流都收敛到相同的吞吐量值。但是，使用Drop-Tail队列有两个挑战：（a）会导致较大的排队延迟（平均队列占用率为71％），这会增加延迟敏感业务的完成时间；（b）相同的吞吐量降低了像DCTCP这样的新协议部署的动力。
B. 使用DCTCP AQM的TCP和DCTCP
接下来验证DCTCP AQM。图3（a）显示了吞吐量随着时间变化的情况（在RTT时间尺度上测量）。图中显示TCP流饥饿，且DCTCP流的吞吐量大约是TCP流的8倍。发生这种情况的原因是：（a）基于瞬时队列长度的DCTCPAQM的积极标记；（b）DCTCP使用了较温和的退避因子。DCTCP使用比TCP更小的退避因子使得保持的平均队列长度接近标记阈值K。由于DCTCP的主动标记，这使得来自TCP流的非常少的分组被容纳在缓冲器中，并且导致频繁的TCP流量回退，从而降低吞吐量。 请注意，保持在1Gbps（请参见图3（b））。
标记阈值K的影响：标记阈值K决定了DCTCP流达到的时延和吞吐量。[2]表明为了避免链路吞吐量的任何损失，K应至少为BDP/ 7。与需要BDP缓冲区来保持全链路吞吐量的TCP不同，由于使用较小的退避因子，DCTCP需求较少。图3表现了随着K值变化的情况。图中显示，随着K增加，从K= 20时的6增加到K= 150时的12，表明DCTCP正在获得更大的瓶颈环节容量份额。发生这种情况的原因是：随着K值，流量竞争更大的缓冲空间，平均队列占用率也随之增大。在较大的缓冲空间中，DCTCP占据较大优势，增加。具体说来，K的值决定了两个流可用的平均缓冲空间。当K增加时，DCTCP保持更大的拥塞窗口，从而维持队列中更大数量的分组。由于DCTCP采用小于TCP的回退因子，因此对于缓冲区中的TCP数据包几乎没有净空。另一方面，TCP的积极回退允许DCTCP流支配缓冲区空间增大。这转化为DCTCP流量的吞吐量的增加和TCP流量的吞吐量的减少。
图3 该图显示了当瓶颈链路使用DCTCPAQM时长DCTCP和TCP流的性能。 （a）显示随时间变化的流吞吐量，（b）显示流的总吞吐量，（c）显示吞吐率与K的函数关系。
总之，当DCTCP与DCTCP共存时，因为DCTCP的激进AQM和较小的回退因子，DCTCPAQM会导致TCP流非常低的吞吐量。而且，取决于标记阈值K。随着K增加，和排队延迟也增加。
C. 使用RED的TCP和DCTCP
DCTCP具有比TCP更高吞吐量的主要原因是其较小的退避因子和交换机上的积极标记，这造成了DCTCP对缓冲区的垄断。这反过来又导致了TCP的经常回退。因此，一个比DCTCPAQM更加公平的数据包标记可以提高协议流的公平性。RED提供了这样的选择。我们现在评估RED下的共存属性。我们使用RED和ECN标记，并研究了最小和最大队列阈值对DCTCP和TCP流的性能的影响。
图4（a）显示了当50，= 100时，DCTCP和TCP流的吞吐量随着时间的变化。图中显示TCP比在使用DCTCPAQM时的吞吐量更好。但是，由于分组的概率标记和随之而来的排队行为，两个流都表现出吞吐量的巨大波动。
的影响： 当我们在保持固定为100的情况下增加时，观察到也增加。发生这种情况是因为收到标记数据包时，TCP比DCTCP更积极地回退。因此，平均而言，DCTCP将会获得更高的缓存份额。请注意，当设置为30时，吞吐率为~2。随着我们将增加到90，吞吐率会增加到3.5。因此，就像DCTCPAQM一样，DCTCP实现比TCP更高的拥塞窗口大小。另一个要考虑的因素是标记概率的变化，这取决于两个阈值之间的差异。随着我们增加，差异（ -）也减少，从而使RED在标记方面更加积极，类似于DCTCPAQM。
的影响：当maxth增加时，标记概率的斜率减小（参见公式（2））。这导致的增加，流量之间正在争夺更大的缓冲空间。但是，反馈效果仍然存在。占主导地位的流量将平均得到更多标记的数据包，流量之间的吞吐量会因此分配得更公平。从图4（c）可以明显看出，当最大值从65变化到200时，流量吞吐量之比从2.7下降到2.25。
总之，RED显着提高了DCTCP和TCP流量之间的公平性。增加会降低公平性，增加可以提高公平性，但这是以增加为代价的，这不利于延迟敏感型业务。
图4该图显示了当瓶颈链路使用RED时长寿命DCTCP和TCP流的性能。（a）显示=50和=100时的流量随时间的吞吐量，（b）时，是的函数（c）显示为的函数。
D. 使用CHOKe得TCP和DCTCP
我们现在评估CHOKeAQM下的DCTCP和TCP的性能。与RED相比，CHOKe的标记政策更为公平。它通过将队列中的随机数据包与到达的数据包进行比较来实现此目的。 如果它们都属于同一个流，则两个数据包都被标记。 图5（a）显示了带有ECN的CHOKe下的吞吐率。CHOKe赋予非主导流量的更高的惩罚，在CHOKe下，获得了比RED下更高的吞吐量。虽然两个数据包的标记由于其较大的窗口大小而不会对DCTCP造成太大的影响，但是会导致TCP流的吞吐量大大降低，从而增加了。
图5该图显示了在具有ECN的CHOKe下单个长寿命的DCTCP和TCP流的性能。 （a），（b）和（c）分别显示了，平均队列长度和α随着变化的过程。
E. 使用改版CHOKe的TCP和DCTCP
我们现在考虑一个CHOKe的修改版本。使用这个版本，当超过时，我们从队列中随机选择“m”个数据包，看它们是否属于与传入数据包相同的数据流。这样做是为了即使在CHOKe中，非主导协议流的数据包也有可能被频繁地标记出来。当以这个标准检查'm'包时，非支配流被标记的可能性被降低。
图6（a）显示了修改后的CHOKe的。我们可以发现图中显示的公平性大大提高。当为30时，为〜1.5，当增加到90时，增加到〜2。发生这种情况的原因是在小的值处，DCTCP流的数据包受到更严重抵制的可能性相对于TCP增加，如图6（b）所示，这相对于其他AQM方案改善了公平性。
由于DCTCP和TCP在RTT中只减少一次窗口，TCP在两个不同的拥塞窗口实例中标记数据包的概率甚至更低，所以TCP主要受到RED标记的影响。 另一方面，DCTCP遭受的回退的频率以及强度都有所增加。
根据等式4，当退避因子是0.215（对应于 = 40）时，应该等于4.6。 但是，根据图6（a）所示的评估结果，低于模型预测的结果。产生这种情况的关键原因是该模型假定协议流接收同步反馈（即具有相同的退避频率）。一个回退小的流，使用相同的增加因子，却观察到更高的回退频率。例如，在这些设置下，通过一次模拟运行，我们发现DCTCP回退约1600次，平均回退系数为〜0.215。 另一方面，即使采用0.5的更积极的退避因子，TCP也只退缩了大约400次。 这导致流量之间更公平的带宽分配。
图6 该图显示了在m= 7并启用了ECN的CHOKe下的单个长寿命DCTCP和TCP流的性能。（a）和（b）分别表示Tr和DCTCPα随着变化的过程。
总之，改进的CHOKe通过更公平地标记了控制主流的数据包，降低处理低吞吐量的流量的概率，改进了RED。
Ⅴ. 数据中心特定的缺陷
我们现在用RED和CHOKe评估数据中心特定场景下DCTCP和TCP的性能。我们首先考虑TCPincast的情况。然后，我们考虑基准设置，在这个基准设置中，对延迟敏感的短流与长流流竞争[2]
A．TCP incast
设置包括几台连接到1 Gbps链路交换机的机器。一台机器充当客户端，其余机器充当服务器。客户端向每个服务器请求1MB/ n的数据量，其中n是客户端请求的服务器总数，服务器响应。这导致了同步的反应，并导致了众所周知的incast现象[1]。在数据中心网络中，我们始终保持一个长期的DCTCP流量和一个长期的TCP流量，这是数据中心网络中常见的情况[2]。图7显示了平均流量完成时间（AFCT），作为incast发生情况下RED和CHOKe发送者数量的函数（注意，设置为70）。我们可以发现在RED和CHOKe下，DCTCP流量与的TCP流量相比，拥有较短的AFCT。 当发送者数量很大时，AFCT的差别更大， 例如，当有90个发送者时，TCP流的AFCT比DCTCP的大2倍以上。
图7 该图显示了在RED和改进的CHOKe的情况下DCTCP和TCP流的AFCT。 被设定为70。
B. 非incast情景
在这种情况下，我们生成两个长期的背景流（一个TCP和一个DCTCP流）。此外，短流量以瓶颈容量的20％提供负载进入网络;数据中心的现实负载。这个负载在TCP和DCTCP流之间平均分配（即每个10％）。短流的到达时间呈指数分布。 流量大小均匀分布在[10KB，50KB]，平均大小为30KB。图8（a）和图8（b）显示，当RED和CHOKe下降时，AFCT均下降。发生这种情况是因为平均队列长度在减少时减少，这反过来又改善了流完成时间。与RED相比，经修改的CHOKe在更高的下导致更公平的AFCT。
Ⅵ. 相关工作
学者们已经提出了几种协议和机制来允许异构传输协议的共存。[14]，[15]建议将每个协议映射到一个单独的队列，并使用共享的加权处理器调度来自队列的数据包。但是，这提出了复杂的管理问题，并且增加了不必要的成本。[16]使用一个单一的队列，但建议对不同的协议使用不同的AQM。[17]提出在仅使用其中一个协议的孤岛中使用协议。
Ⅶ. 结论
在本文中，我们研究了DCTCP和TCP的共存性质。我们发现DCTCPAQM可能会导致TCP流量不足。我们的研究结果表明，在RED下，DCTCP明显优于TCP（至少2倍），适应参数并不能提高公平性。我们发现CHOKe降低了公平性。 我们提出了CHOKe的修改版本，通过精确检测主流，大大提高了公平性。 今后，我们计划研究使用异构应用程序的实际测试平台上的协议互操作性。在未来，我们计划在一个使用异构应用程序的真正测试平台上研究协议的互操作性。
文献引用
[1] D.Abts and B. Felderman, “A guided tour of data-center networking,”Communications of the ACM, vol. 55, no. 6, pp. 44–51, Jun. 2012.
[2] M. Alizadeh,A. Greenberg, D. Maltz, J. Padhye, P. Patel, B. Prabhakar,S. Sengupta, and M. Sridharan, “Datacenter tcp (dctcp),” in ACMSIGCOMM’10.
[3] B.Vamanan, J. Hasan, and T. N. Vijaykumar, “Deadline-aware datacenter tcp(d2tcp),” in ACMSIGCOMM’12.
[4] C.-Y.Hong, M. Caesar, and P. B. Godfrey, “Finishing flows quickly withpreemptive scheduling,” in ACM SIGCOMM’12.
[5] A. Munir,I. A. Qazi, Z. A. Uzmi, A. Mushtaq, S. N. Ismail, M. S. Iqbal,and B. Khan, “Minimizing FlowCompletion Times in Data Centers,”in IEEEINFOCOM’13.
[6] M.Alizadeh, S. Yang, M. Sharif, S. Katti, N. McKeown, B. Prabhakar,and S. Shenker, “pfabric: Minimalnear-optimal datacenter transport,” inACM SIGCOMM’13.
[7] S. Floydand V. Jacobson, “Random early detection gateways for congestion avoidance,” inIEEE/ACMTransactions on Networking, 1(4):397-413,Aug 1993.
[8] R. Pan,B. Prabhakar, and K. Psounis, “Choke, a stateless active queuemanagement scheme for approximatingfair bandwidth allocation,” inIEEEINFOCOM’00.
[9] R.Shorten, F. Wirth, and D. Leith, “A positive systems model of TCPlikecongestion control: Asymptotic results,” IEEE/ACM Transactionson Networking, vol. 14, pp. 616–629, 2006.
[10] M.Corless and R. Shorten, “Deterministic and stochastic convergenceproperties of aimd algorithms withnonlinear back-off functions,” inAutomatica 2011.
[11] V.Vasudevan, A. Phanishayee, H. Shah, E. Krevat, D. Andersen,G. Ganger, G. Gibson, and B. Mueller,“Safe and effective finegrained tcp retransmissions for datacenter communication,”in ACMSIGCOMM’09.
[12] H. Wu,Z. Feng, C. Guo, and Y. Zhang, “Ictcp: Incast congestion controlfor tcp in data center networks,” in ACM CoNEXT’10.
[13] G.Appenzeller, I. Keslassy, and N. McKeown, “Sizing router buffers,”in ACM SIGCOMM’04.
[14] C. H.Tai, J. Zhu, and N. Dukkipati, “Making large scale deployment ofRCP practical for real networks,” in IEEE INFOCOM Mini-Conference,2008.
[15] N.Dukkipati, M. Kobayashi, R. Zhang-Shen, and N. McKeown, “Processor sharingflows in the internet,” in IWQoS,2005.
[16] I. A.Qazi, L. L. H. Andrew, and T. Znati, “Incremental deployment ofnew ECN-compatible congestion control,”in PFLDNeT, Tokyo, Japan,May 2009.
[17] D.Katabi, M. Handley, and C. Rohrs, “Internet congestion control forhigh bandwidth-delay product networks,”in ACMSIGCOMM’01.
