Survey on TCP Incast Problem in Datacenter Networks-2016

TCP Incast and Cloud application performance--Brad Hedlund's blog20110501

Incast问题来自于分布式存储和计算架构，例如Hadoop、MapReduce、HDFS、Cassandra等等，还有一些应用，例如web搜索，maps，社交网络，数据仓库和分析等。使用分布式存储架构可以增加服务器集群的计算存储和处理能力，随着服务器集群规模的增大，对应用性能的影响有利有弊。优势是增加应用性能，越大的集群会提供更高的分布式处理能力，更多的工作会完成的更快。劣势是增加了前端服务器发生incast拥塞的几率，同时也会降低单个服务器的吞吐量。

实际应用中，云数据中心仍在不断的增加服务器集群的规模，因此我们要确定：Incast拥塞问题对应用性能的影响到底有多大？我们怎样才能准确的测量和降低incast问题带来的影响？

TCP的变种DCTCP优化了拥塞监测方案，能够最小化收到incast影响的数据集，最小化丢包率和重传时延。优势是降低了交换机缓冲区的利用率，减轻了交换机缓冲区的负担。缺点是只有长流DCTCP才能精确监测到拥塞并作出反应，短流效果不明显。

更优的方案就是：高性能的交换机+DCTCP等优化方案。其中交换机可以处理micro burst的incast问题，DCTCP可以对较长的流处理incast问题。

Incast 问题示意图

incast的增加的时延取决于TCP的RTO设置，广域网环境中一般为200ms。数据中心环境要降低两个三个数量级。

Incast的超时重传的时延主要来自于两种时延：Block Tail time out (BTTO) and Block Head Time out (BHTO) 。BTTO块尾部超时指的是同时连接的服务器数量较少，但某个块中的发送端发送的最后一个或几个数据被丢弃了，此时就要等要RTO结束后重传该数据包。这是TCP incast的固有属性，当所有数据块都全部被接收到时，发送端（服务器端）才会初始化下一个数据块。BHTO块头部超时指的是同时连接的服务器数量很多的情况。服务器端数量过多，发送窗口同时被占满，交换机缓存空间不够，造成大量块数据的丢失，需要RTO结束后才能重传。

解决方案：

基于优先级的解决方案（PRIN）：在开始将降低每个服务器的拥塞窗口值，避免了BHTO。然后将每条流的最后三个包设置为高优先级，避免了BTTO。在linux内核上实现了，修改了TCP包头。

随机调整TCP方案（SA-TCP）：随机调整拥塞窗口避免并行流的同步。就是TCP的AIMD，加法增加，乘法减少。加法增加的步长是随机的，乘法减少还是对半。优势：只用修改发送端的拥塞窗口，是传输层的TCP协议的变种解决方案。缺点：未考虑交换机缓冲区大小。

流感知拥塞控制：数据中心流量特征：10%数量的长流占据80%的吞吐量，是吞吐量敏感的流，例如热迁移，软件更新，分布式数据处理应用等等。短流是时延敏感的流，主要对应查询搜索，远程调用等等。在incast情况下，长流受到的影响更大。那么，本方案就是要避免长流受影响。每条长流的IP头部的DSCP字段都是一个特殊的值，在TOR交换机上，当遇到拥塞时，会将所有的包都打上CE（拥塞）标签（就是ECN字段修改），在receiver端，当匹配到DSCP值为特定值时，则将其CE标签去掉，这样，发送长流的服务器就不会降低拥塞窗口，吞吐量也不会降低。

优势：不用修改TCP协议栈，长流的吞吐量不会降低，相比于SDN解决方案（集中式控制器不能很快的解决incast问题），该方案能在交换机上解决incast问题，克服了集中式控制的缺点。ECN机制避免了不必要的丢包，并且在丢包后等待源端重传数据的过程中，该TCP连接也不会空闲。

缺点：一是需要一个专用的交换机来为目标流打标签，可能会需要数据中心网络中硬件平面上的修改；二是ECN包固有的缺陷，即ECN包（包括源Quench消息和ECN字段修改了的ACK包）在到达TCP发送端之前就有可能被网络丢掉。

主动感知控制（PAC）：核心思想为在接收端控制ACK的发送间隔时延。本方案主要思想为在接收端维持一个ACK队列，当收到数据包时不要立刻回传ACK，而是将其放在队列中，当发现有足够的内存空间可以容纳ACK数量的新数据包时，再回传ACK。也就是说ACK的发送不再是连续不断的，而是要考虑发送的时间和缓冲区具体状态。将交换机缓存大小作为ACK控制算法的初始化门限值。缺点：数据中心中交换机缓冲区大小差异较大，将交换机缓冲区大小作为ACK控制算法的初始值会不妥，使用ECN作为拥塞标记，ECN固有的属性会在未到达发送端之前被丢包。

相关工作中将incast解决方案分为两类：一种是基于窗口大小调整的，一种是基于恢复的。基于窗口大小调整的典型方案有DCTCP和ICTCP，思想为调整拥塞窗口大小避免交换机缓冲池的溢出和丢包。缺点：拥塞窗口的最小值是受限的，为一个最大分段长度，因此为了保证不发生incast问题，发送端的数量会受到限制。基于回复的方案主要思想为最小化RTO，即最小化丢包后的影响。TCP的特性为当发生丢包后RTO时间一到会立即重传，不用等到链路空闲。

评价方案指标：同时连接的发送端数量，是否需要对TCP/IP协议栈做修改，是否需要额外的硬件或专用交换机之类的成本引入。

M21TCP：由交换机告知连接的服务器此时有多少服务器也同时连接在该交换机上并与前端服务器通信。后端服务器会根据此消息限定自身拥塞窗口大小，达到避免incast拥塞的效果，对比方案为RED和ECN。此方案同时利用了传输层和网络层，利用了基于流控制方案的路由/交换机思想。缺点是该方案只针对单路径TCP设计。

survey中方案关键参数对比