ICTCP-阅读笔记

IEEE/ACM Transactions on networking，2013

简介

应用层与传输层解决方案的区别：应用层级的解决方案不具有通用性，只适用于同一种应用，例如PICC。而传输层级的解决方案可以屏蔽不同应用间的区别，更具有通用性。

实验中每个发端发送的数据数量是相同的，总的流量会随着发端数量的增加而增加。在某些文章中，是将总流量固定为一个定值，随着发端数量的增加，单个发端发送的数据量减少。

方案思想：基于接收窗口的拥塞控制算法。在丢包前进行拥塞避免，避免丢包。理论依据为接收端可以获取目前全局的有限吞吐量和可用剩余带宽。难点在于如果接收窗口大小过小，会限制TCP性能，过大则失去了预防incast拥塞的作用。

解决步骤：（1）在接收端执行拥塞控制算法，用剩余带宽作为调节接收窗口的评价标准（2）每条流的接收窗口的调节都是独立的（3）接收窗口的调节是基于测量吞吐量和理想吞吐量之间差值的百分比，以及RTT往返时延来确定的。

背景和动机

1. 介绍了incast问题发生的情景
   每个TCP连接传输的数据块大小都是比较小的， 为kB量级的，一般测试用的数据块大小在64kB，128kB，256kB，等等。同时连接的服务器数量在44-48之间，TOR交换机一般情况下是48个端口，上行链路带宽大约为单个端口10Gb。

goodput指的是多个TCP连接的有效吞吐量，是在应用层测量得到的。在实际测试中，接收端先通过多线程向所有发端发送请求，TCP连接是逐个发出的，当该轮上的所有连接都已完成向接收方的数据传输时，一轮结束。

探讨了并行发端数量与有效吞吐量之间的关系，得出结论，在最后一跳解决incast问题。

2. goodput，接收窗口，RTT
   探索了静态接收窗口下goodput和RTT的变化情况，分析了其他根据RTT调整接收窗口的方案，得出结论，增加的时延就是因为排队，但单纯依据RTT调整接收窗口，不靠谱，一是RTT测量的精确度本身与系统相关性较大，二是RTT增加时，可用带宽并不一定增加，这时增加接收窗口只会造成丢包。

方案只调整RTT小于2ms的TCP流，这样，该拥塞避免算法就可以只应用于多对一模式的流量，避免了其他长流的吞吐量下降。

3. incast问题的根源探索
   从时延的组成分析，根源在于交换机出口的排队。定义了BDP（带宽时延产品），理论计算了不发生incast问题时允许同时发送的数据包个数为8个。指出现代TOR交换机的缓存一般为4MB，平均每个端口为85kB。只有使用好交换机缓存空间，才能保证不丢包，吞吐量不下降。调节方案有两种：发端拥塞窗口和收端接收窗口。本文选择收端接收窗口。

设计

ICTCP方案具有通用性，既可以调节incast流，也可以调节非incast流。没有对TCP协议和TCP包头做任何修改，具有很强的兼容性。在拥塞发生前避免，而不是拥塞发生后快速恢复，避免了丢包。

研究场景为典型的incast场景：多个服务器连接在同一个交换机上，接收端为单个，也连接在该交换机上。该算法只针对低时延流，即RTT小于2ms的流。若一台服务器同时与数据中心内服务器通信，又与外部服务器通信，则该算法只会对内部服务器的流起作用。在后文中也测试了该算法在背景流量方面的性能。

ICTCP的基础：

1. 接收端的可用带宽是接收端实行拥塞控制的信号。
2. 接收窗口的调整间隔应大于1个RTT，否则调整无效，不会应用到下一轮数据发送中。
3. 接收窗口的设置在满足应用吞吐量的要求的前提下，应检查是否过大。否则若该应用重新请求，则很可能会因突发流量造成incast拥塞。

基于以上基础，ICTCP算法的思想就是为共享同一个最后一条的所有TCP连接分配合适的接收窗口。保证正常的TCP连接的性能不能下降，多对一TCP流的incast问题可以避免。由于多对一流的性能由最慢的一条TCP连接决定，因此还要考虑多对一TCP连接中的接收窗口公平性问题。

ICTCP算法

1. 控制触发：可用带宽
   

   假定接收端对每条TCP连接都有一个接口，可统计该流的信息，例如吞吐量等。可用带宽计算公式：
   可用剩余带宽计算公式
   。其中α为0.9。α值越大，越接近一，表示需要更谨慎的调整接收窗口，吞吐量会更大，对交换机的缓存区空间要求越高。α值越小，表示是需要更积极的约束接收窗口大小，这样会造成不必要的吞吐量下降。

每个时间片分为两个子时间片，第一个子时间片，测量每个网络接口的流量，然后计算可用剩余带宽作为在第二个子时间片是否要进行接收窗口增加的判断依据。

注意：第一个时间片内不会发生接收窗口增加的动作，在监测到拥塞时，第一时间片有可能减少接收窗口。任意一条TCP流的接收窗口减少，都不会更新可用剩余带宽的值，这个值只有在下一个第一子时间片才会更新重置。

2. 每条连接的控制间隔：两个RTT
   

   至少要经过一个RTT的时间，才能使上一轮调节的接收窗口生效，因此本方案中设置的每条连接的控制间隔为2个RTT。每条连接的调节都是相互独立的。但由于不同连接的RTT不同，因此子时间片的设置要考虑到所有活动的流的RTT，即自时间片长度设置为
   子时间片长度计算公式
   ，其中w表示第i条连接在上一个时间T的流量的归一化因子。

举例说明，假如当前时刻为全局控制间隔的第二个子时间片，某条流i在此时距离上次调整接收窗口的时间间隔大于2倍的该流的RTT，并且可用带宽满足条件，此时可以增加接收窗口。

3. 单条连接的窗口调整
   测量的吞吐量Bm，期待的吞吐量Be，采样的吞吐量Bs，其中Bs计算公式为用一个RTT时间间隔内接收端收到的字节数除以RTT。Bm的更新公式如下

   
   
   Bm更新公式
   在实验中β值为0.75.期待的吞吐量Be测量公式如下
   Be计算公式
   这样就保证了测量的吞吐量的上限值为期待的吞吐量。

ICTCP方案中将期待吞吐量与测量吞吐量之间的差值比作为判别接收窗口是否增加或减小的依据。在之前的方案TCP Vegas中，是用期待吞吐量与测量吞吐量之间的差值作为判断依据，并且是在发送端实行控制拥塞窗口的方式进行拥塞控制的。ICTCP方案的Db表示差值比，计算公式如下：

差值比计算公式

其中差值比的取值范围为0-1.根据差值比，设置了两个阈值γ1（取值为0.1）和γ2（取值为0.5）。

• 当差值比小于等于γ1或MSS除以接收窗口的比值时，若此时处于全局的第二个子时间片，且有足够的可用带宽，则增加接收窗口，并将增加的接收窗口在总的可用带宽减掉（减去带宽的计算公式为增加的MSS除以RTT），避免多条流同时增加接收窗口时引发的overdescribed。慢启动阶段。
• 当差值比大于γ2时，并且连续三个RTT的测量结果都是这样，此时减小接收窗口，减掉一个MSS，接收窗口最小为2*MSS。拥塞避免阶段
• 其他情况下，接收窗口保持不变。

4. 维持多条连接公平性的控制器
   当可用剩余带宽小于0.2C时，则将接收窗口大于平均接收窗口值的连接的接收窗口减去一个MSS。若所有连接都拥有相同的接收窗口，则所有连接均不会减小。
   这种公平性机制主要针对这种情景，较早启动的连接拥有较大的接收窗口，较晚启动的接收窗口较小。此时所有连接均不能增加接收窗口，因为没有足够的可用带宽了，只要不出现丢包，这种状态会一直维持下去，这就会引发TCP连接间的公平性问题。所以ICTCP算法设置了剩余带宽门限，通过微调不同连接间的差异，使得所有TCP连接实现平稳收敛。

分析（介绍了ICTCP方案的合理性，建立了简单的流模型）

建立了稳态下的流模型，此时所有流的接收窗口已被优化，建立此模型的目的是从理论上讨论在稳态下，所需的交换机缓存空间是多少，现有交换机缓存能否支持ICTCP算法的运行。

n条流的bdp等于接收端链路的BDP=R*C

单条流在交换机中排队的数据包数

缓存大小的约束公式

在极端情况下，即网络中还没有ack包，所有数据包都朝着接收端方案传输，此时所需要的缓存大小为

最坏情况下的交换机缓存大小约束

在上述公式的基础上，将现有48口交换机的相关数据带入，得出当48个端口同时发生排队情况下，每条流的接收窗口为两个MSS，C=1Gbps，RTT=100微秒时，所需的交换机缓存为6MB。而现有交换机缓存为4MB，因此在最坏情况下，允许同时并发的发端数量为32台。

实现和评估部分未读