TCP Incast 问题分析

TCP INCAST解决思路

 

应用场景:在集群文件系统内,客户端应用请求某个逻辑数据块(通常情况下一个读数据块大小是1MB),该数据块以条带化方式分别存储在几个存储服务器上,即采用更小的数据片存储(32KB,256KB等),这种小数据片称为服务器请求单元(SRU)。只有当客户端接收到所有的服务器返回的其所请求数据块的SRU后才继续发送出下一个数据块请求,即客户端同时向多个存储服务器发起并发TCP请求,且所有服务器同时向客户端发送SRU。

出现的问题

1)         这种多对一的服务器向客户端并发传输数据的模式,很容易造成与客户端相连接交换机端口的缓冲区溢出,从而导致丢包及随后的TCP重传。在丢包严重的情况下,TCP将经历一个最少持续200ms的超时期,这由TCP最小重传超时(RTOmin)确定。

2)         在并发传输过程中,当某个服务器发生了传输超时但其他服务器完成了传输,则客户端在接收到剩余SRU之前必须等待至少RTOmin,而等待期间客户端的链路很有可能处于完全空闲状态,这就导致在应用层的可见吞吐量与链路容量相比较显著下降且总的请求延迟将高于RTOmin。

切入角度:

深入研究瓶颈链路吞吐量下降甚至降为0,使得瓶颈链路处于完全空闲状态,带宽利用率极低的问题。

若不会发生TCP Incast问题,瓶颈链路的吞吐量会保持在一定范围内波动,带宽利用率也会较高。

当TCP Incast现象发生了,一旦多个SRU发生超时重传,其他完成数据传输的SRU必须等待其超时重传的SRU传输完成,客户端才可以发送下一个数据块请求。这样在成功发送完的SRU和正在等待超时的SRU交叠的时间块上,瓶颈链路的吞吐量降为0,带宽利用率同时也会降为0.

具体的例子:

假设一共有10个服务器请求单元:SRU1,SRU2…SRU9,SRU10;

其中SRU2,SRU3,SRU6发生超时重传,其他服务器请求单元要在完成传输后等待SRU2,SRU3,SRU6传输完成。而此时,SRU2,SRU3,SRU6正在等待超时。

处于这种情况下,7个成功发送数据的服务器正在等待3个未成功发送数据的服务器超时重传,这段时间内,瓶颈链路的吞吐量降为0,处于完全空闲状态,同时带宽利用率也为0。

根本原因分析:

1)         障碍同步机制(应用本身的问题,前提条件)

2)         我们发现瓶颈链路吞吐量下降为0的时间不仅仅和超时等待的RTO有关系。

²  若拥塞发生在7个成功发送数据的服务器之后,3个未成功发送数据的服务器将等待超时,此时,瓶颈链路将没有数据传输,吞吐量降为0,带宽利用率为0。Time(瓶颈链路吞吐量=0)> RTO;

²  若拥塞发生在7个成功发送数据的服务器之前,3个未成功发送数据的服务器即使在等待超时,瓶颈链路仍然有数据在传输,吞吐量不会降为0,带宽利用率也会保持在一定范围内。此时Time(瓶颈链路吞吐量=0)< RTO;

²  事实上,一个发送端超时了,有可能其他的发送端还在继续发送数据,此时瓶颈链路仍然有数据在发送。这样来说瓶颈链路的带宽利用率,吞吐量大小是由超时等待的时间长短(RTO)与未超时的流的传输时间共同决定的。

解决方法:

         一方面,我们减少超时等待的流的个数以延长处于障碍同步的流的个数,另一方面,我们减少超时等待的时延以使瓶颈链路吞吐量为0的时间进一步减少。

         一方面增加成功的发送端的个数,拉长其传输时间以使瓶颈链路一直有数据在传输,不至于让吞吐量降为0。另一方面缩短未成功的发送端的超时等待时间RTO。

1)         减少超时重传的服务器个数(本质上丢包是无法避免的,丢包解决不了只能从快速重传,快速恢复来切入。但是有的情况下无法触发快速重传机制,只能等待超时。我们就是要减少这种情况的发生,将那些超时等待的情况转变为快速重传

超时的原因主要分为三个方面:数据块头部,数据块尾部,数据块重传丢失

数据块头部超时:

²  拥塞窗口值较小的流不幸丢掉了窗口所有的数据包,由于没有ACK 回来,所以只能等待超时重传。

数据块尾部超时:

²  块尾倒数三个数据包中的任何一个包丢失都会导致发送端超时。

数据块重传丢失

²  另一个重要的超时是重传的包丢失。当tcp的发送端通过监测发现了丢包,会立即快速重传丢失的包。然而如果重传的包再一次丢失。发送端就只能等待超时。

 

针对数据块头部超时,其实本质上慢启动过程中的不公平现象。当一个回合的传输开始时,所有的发送端进入慢启动阶段。在慢启动阶段拥赛窗口按指数级增长,由于发送端窗口增长的步伐并不是一致的,先启动窗口增长过程的发送端取得竞争带宽的优势,这种优势会随着指数级的窗口增长被逐渐放大,等到网络拥赛时,所有的发送端的窗口大小是层次不齐的。拥塞窗口值较小的流就有可能全部丢失,被迫超时重传。

所以我们要设计策略提高慢启动阶段的公平性。如果有一个集中的控制器,它知道所有流的占据的带宽值并据此调整他们的发送速率。交换机完全可以充当这个集中的控制器,当所有流经过交换机时,交换机计算所有流的平均窗口值AVG,通过ACK显示回馈给发送端。发送端统一将发送窗口调整为AVG大小来公平的分配带宽。

针对数据块尾部超时,本质上是由于没有足够的ACK触发快速重传。我们只要重传数据块尾部最后一个数据包,即能够产生足够的ACK触发快速重传,也不需要产生和处理新的数据包。

针对数据块重传丢失,这个问题我们可以选择概率性重传那些需要重传的包。减小这种情况的发生概率。

2)         动态调整RTO的值(根据拥塞程度)

posted @ 2016-07-12 13:19  kun先生  阅读(6219)  评论(0编辑  收藏  举报