整体论文梳理
方案设计
-
CP方案主要过程
- CP交换机有存储等待转发包的缓冲区,当缓冲区满的时候,有一个新的CP-enable的包到达,交换机会修剪这个包的负载。
- 在这个过程中:包会标记为一个payload-cut packet,IP的长度被保存给接受者计算包的大小,TCP的校验和被重新计算和修改。
- 没有负载的重新生成的包在缓冲区中和其他包一样排队等待转发
-
由于保留了IP字段长度,被修剪负载的包可能会被现代交换机ASIC或中间盒丢弃
-
PACK介绍
- PACK设计关键
- 修剪之后如何确定左右边界
- 如何表示丢失包的信息,以便和SACK兼容
- 以上两个问题解决方法
- 由于保存了IP长度左边界可以很容易从报头得出,右边界可以根据左边界算出
- 我们将交换左右边界去表示一个修剪包信息(优点:不会产生冲突,因为左边界比右边界小)
- 当修剪包到达的时候,接受者会对其进行解析,将丢失包的信息放入PACK选项中第一个块
- PACK设计关键
-
每个包有四个状态:“SACKed”,“out-of-order”,“lost”,“retransmitted”,当包开始重传的时候,状态改变为“out-of-order”
-
当接受者收到包的时候
- 分析PACK选项,检查包状态,如果包的状态是”SACKed“ or “out-of-order” 不做什么,否则进行第二步
- 将包状态改为“lost”,将包加入重传队列
- 如果TCP不在快重传状态,则触发快重传
- 当包被重传的时候,状态修改为“retransmitted”
论文思路
- 数据中心具有更短RTT,更高带宽,高度可变流量,低延迟等需求,TCP无法满足性能问题
- 面临的问题:TCP incast,TCP outcast,TCP out-of-order,询问请求完成时间长,吞吐量悬崖,不公平性。
- 原因:self-clocking,ambiguous loss indication,slow packet loss detection
- 解决方法:CP:packet loss notification
- CP只会修剪包的payload 而不是整个包
- 利用PACK(SACK-like)准确告知发送者丢失包信息
2.1 low and Volatile Throughput
- 在现实生活中有很多多对一模式(多个发送者同时发送给同一个接受者)
- 结果:造成TCP incast collapse 普遍发生,吞吐量急剧下降
- 已经提出的解决方法:DCTCP,ICTCP,减小 R T O m i n RTO_{min} RTOmin ,但是不能满足Mapreduce和网页搜索两种应用
- 在Mapreduce应用中: 发送者过多 → \to → 丢包,重传 → \to → 超时,现今应用的缺点:DCTCP,ICTCP对发送者有一个上限(显然无法满足现在的需求), R T O m i n RTO_{min} RTOmin会造成吞吐悬崖
- 在网站搜索应用中:请求完成时间产
2.2 TCP unfairness
- TCP不公平性又分两种情况
- single-bottleneck
- multi-bottleneck
- 在single-bottleneck :当有large和small 流量从不同发送方发送给同一个接收方,超时优先发生在small 流量上,造成TCP outcast → \to → 通过核心路由器改变路由路径解决这个问题 → \to → 这样会增加核心路由器的压力和端到端延迟
- multi-bottleneck:
2.4 Long Query Completion Time
- 询问完成时间受到排队延迟量和重传时间的影响
Abstract
- TCP问题逐渐增加,例如:TCP incast , TCP outcast,long query completion times
- 问题的根源是现有的技术不能够维持自时钟,或者准确快速的包丢失提醒
- 我们提出CP,在过载的交换机中cutting payload,并且告知发送者丢包
- 实验显示CP解决了TCP问题