Catch the Whole Lot in an Action Rapid Precise

整体论文梳理

方案设计

1. CP方案主要过程

   1. CP交换机有存储等待转发包的缓冲区，当缓冲区满的时候，有一个新的CP-enable的包到达，交换机会修剪这个包的负载。
   2. 在这个过程中：包会标记为一个payload-cut packet，IP的长度被保存给接受者计算包的大小，TCP的校验和被重新计算和修改。
   3. 没有负载的重新生成的包在缓冲区中和其他包一样排队等待转发

2. 由于保留了IP字段长度，被修剪负载的包可能会被现代交换机ASIC或中间盒丢弃

3. PACK介绍

   1. PACK设计关键
      • 修剪之后如何确定左右边界
      • 如何表示丢失包的信息，以便和SACK兼容
   2. 以上两个问题解决方法
      • 由于保存了IP长度左边界可以很容易从报头得出，右边界可以根据左边界算出
      • 我们将交换左右边界去表示一个修剪包信息（优点：不会产生冲突，因为左边界比右边界小）
   3. 当修剪包到达的时候，接受者会对其进行解析，将丢失包的信息放入PACK选项中第一个块

4. 每个包有四个状态：“SACKed”，“out-of-order”，“lost”，“retransmitted”，当包开始重传的时候，状态改变为“out-of-order”

5. 当接受者收到包的时候

   1. 分析PACK选项，检查包状态，如果包的状态是”SACKed“ or “out-of-order” 不做什么，否则进行第二步
   2. 将包状态改为“lost”，将包加入重传队列
   3. 如果TCP不在快重传状态，则触发快重传
   4. 当包被重传的时候，状态修改为“retransmitted”

论文思路

1. 数据中心具有更短RTT，更高带宽，高度可变流量，低延迟等需求，TCP无法满足性能问题
2. 面临的问题：TCP incast，TCP outcast，TCP out-of-order，询问请求完成时间长，吞吐量悬崖，不公平性。
3. 原因：self-clocking，ambiguous loss indication，slow packet loss detection
4. 解决方法：CP：packet loss notification
   1. CP只会修剪包的payload 而不是整个包
   2. 利用PACK（SACK-like）准确告知发送者丢失包信息

2.1 low and Volatile Throughput

1. 在现实生活中有很多多对一模式（多个发送者同时发送给同一个接受者）
2. 结果：造成TCP incast collapse 普遍发生，吞吐量急剧下降
3. 已经提出的解决方法：DCTCP，ICTCP，减小$RT{O}_{min}$ ，但是不能满足Mapreduce和网页搜索两种应用
4. 在Mapreduce应用中： 发送者过多 $\to$ 丢包，重传 $\to$ 超时，现今应用的缺点：DCTCP，ICTCP对发送者有一个上限（显然无法满足现在的需求），$RT{O}_{min}$会造成吞吐悬崖
5. 在网站搜索应用中：请求完成时间产

2.2 TCP unfairness

1. TCP不公平性又分两种情况
   1. single-bottleneck
   2. multi-bottleneck
2. 在single-bottleneck ：当有large和small 流量从不同发送方发送给同一个接收方，超时优先发生在small 流量上，造成TCP outcast $\to$ 通过核心路由器改变路由路径解决这个问题 $\to$ 这样会增加核心路由器的压力和端到端延迟
3. multi-bottleneck：

2.4 Long Query Completion Time

1. 询问完成时间受到排队延迟量和重传时间的影响

Abstract

• TCP问题逐渐增加，例如：TCP incast ， TCP outcast，long query completion times
• 问题的根源是现有的技术不能够维持自时钟，或者准确快速的包丢失提醒
• 我们提出CP，在过载的交换机中cutting payload，并且告知发送者丢包
• 实验显示CP解决了TCP问题