【论文评析】Time-division TCP for Reconfigurable Data Center Networks（可重构数据中心网络的时分TCP）

zq.xidian

于 2024-10-01 10:51:30 发布

阅读量442

点赞数 21

分类专栏：论文评析文章标签：网络 tcp/ip 重构计算机网络网络协议

本文链接：https://blog.csdn.net/zq563100792/article/details/142668704

版权

论文评析专栏收录该内容

1 篇文章 0 订阅

订阅专栏

Time-division TCP for Reconfigurable Data Center Networks

文献信息：

作者：Shawn Shuoshuo Chen, Weiyang Wang, Christopher Canel

类型：会议论文（Proceedings of the ACM SIGCOMM 2022 Conference）

标题：Time-division TCP for reconfigurable data center networks

关键词：RDCN，传输层协议，拥塞控制

引用格式：

@inproceedings{tdtcp,
author = {Chen, Shawn Shuoshuo and Wang, Weiyang and Canel, Christopher and Seshan, Srinivasan and Snoeren, Alex C. and Steenkiste, Peter},
title = {Time-division {TCP} for reconfigurable data center networks},
year = {2022},
booktitle = {Proceedings of the ACM SIGCOMM 2022 Conference},
pages = {19–35},
}

注意撰写论文时参考文献bib中title栏的TCP要打大括号大写，否则latex默认会设置为小写。请注意检查。

CHEN SHAWN SHUOSHUO, WANG WEIYANG, CANEL CHRISTOPHER, et al. Time-division TCP for reconfigurable data center networks[C]. //Proceedings of the ACM SIGCOMM 2022 Conference,2022,19–35.

一，论文背景

当前的数据中心网络面临着高带宽、低时延的挑战，基于光互连架构的可重构数据中心网络是极具前景的方案。然而TCP协议的拥塞控制机制不适用于带宽和时延剧烈变化的网络，各种现有的TCP变体又无法充分利用可重构网络中的带宽资源。

TDTCP需要解决的几个问题：

光学配置仅需几个RTT，主机来不及对新网络环境作出反应；解决：ToR交换机发送通知
跨TDN问题，一个数据包的传输可能横跨两个TDN；解决：跟踪关联TDN ID
内核实现问题，内核中拥塞控制代码被紧密集成；解决：在TDN间复制CUBIC

二，论文动机

Hybrid demand-oblivious RDCNs混合需求不敏感型可重构数据中心网络

时分复用。 在转发数据包时，ToR选择EPS网络或OCS网络，每个状态称为时分网络TDN；
网络特征不同。 分组网络和光网络具有不同的带宽和端到端时延；
TDN特性稳定。 路径上的带宽、延迟和丢失率在相对较小的范围内振荡；
TDN模式可预测。 光网络采用类似Rotornet方法，一周期内遍历连接（需求不敏感）；
路径转换频繁。 为了保持利用率，光网络占空比要高，由于光重构时间短，故转换频繁；

图1：一种混合的、需求不敏感的Rdcn拓扑

Measuring TCP performance in RDCNs 可重构数据中心网络的TCP性能测量

测试单路径TCP（CUBIC），多路径TCP（MPTCP）能否充分利用RDCN容量

测试方法：Etalon RDCN 仿真器

在这里插入图片描述

单路径TCP CUBIC和MPTCP都远低于最优线，表明两者都没有充分利用RDCN带宽；

CUBIC因为其假定了变化缓慢的单一路径，面对路径切换会花较长时间发现和适应；
MPTCP因为其子流的严格隔断机制，切换后旧子流等待路径切回或重传；故不适合RDCN环境，因为RDCN环境中每次只有一条路径处于活动状态。

三，设计思路

Per-TDN state variables（TDN状态变量）

一条时分多用路径可以视作不同的路径，TDTCP 独立地对不同 TDN 的路径特征进行建模，模型的参数分为三类：

pipe变量用于估计飞行、丢失、重传的字节数（让TCP了解“管道”有多满）；
拥塞控制变量用于控制允许进入网络的字节数，以及发送方是否应该减速；
Delay/RTT变量用于跟踪路径延迟；
以及TDN ID，即网络路径的整数索引，来处理跨TDN重排和假重传；

不同TDN的模型参数一般只在活动状态改变，非活动状态在跨TDN情况时会更新；

TDN change notification（TDN变更通知）

TDTCP采用带外通知方式，即需要服务器获知网络状态变化，ToR交换机通过ICMP告知下游服务器，ICMP报头携带TDN ID；

带内方式即数据包标记、网络探测；
带外方式保证通知能及时到达，而不会在带内拥塞；

服务器能及时且准确地获得TDN ID至关重要；

Sequence numbering（序列编码）

TDTCP给数据包做了一个连续的编号，TDN变化不影响编号的继续，用于实现跨TDN操作；

MPTCP对每个路径有单独序列号，保证了各路径独立运行和兼容性；
论文假设数据中心网络对网络设备与功能有充分的控制权，因此不考虑兼容性；

Packet reordering（数据包重排序）

问题：跨TDN会导致乱序，TCP Reno中的快恢复机制（收到三个重复确认重传）会误判丢包；即图中的在ACK123之前收到ACK456；

在这里插入图片描述

(a)数据包乱序；(b)ACK乱序；前者会引起PKT456重传（ACK456内容其实是上一个包的重传信息），后者不引起（ACK已更新为456）；

解决方法：Relaxed detection（松弛检测），即检测发生乱序的TDN ID，TDN变化指针跟踪上一个TDN的最终序列号/新TDN的第一个序列号。相同则发生了跨TDN乱序，忽略重传，比如图中的蓝色虚线包；不同则说明确实丢失，比如红色虚线包；

在这里插入图片描述

图中处理为：TDN 0保持在打开状态，并允许继续以全速发送；TDN 1由于丢包的原因进入快恢复状态。

Fairness, generality, and limitations（公平性、普适性、局限性）

公平性：每个TDN的拥塞控制算法相同，都采用CUBIC（可改进）；

普适性：TDTCP可服务于各种用例，也特别适合周期变化的网络如卫星通信；

局限性：TDTCP局限于网络条件特定频率变化的场景；变化周期1-100个RTT；

四，实施方案

数据包格式

a是用于通知服务器TDN变化的ICMP包结构；

b是TCP握手选项，其中定义了子类型TD_ABLE表示服务器支持TDTCP，TDNs为服务器获知的TDN数量；

c是TCP路径选项，包含数据包和ACK的TDN ID；

在这里插入图片描述

建立连接

通过图b所示数据包建立连接，b中子类型表示支持TDTCP，之后两端统一TDNs；

建立连接后，图c所示数据包子结构TD_DATA_ACK携带该网段发送到的TDN ID；如果该段包含数据，数据TDN ID字段和D bitflag集合应该被适当填充，ACK包同理；

TDN状态管理

TDN状态变量可分为四个种类：

Current TDN，状态完全在当前的TDN内计算；比如packet_out，仅对当前TDN内数据包统计；
All TDN，需要考虑其他TDN状态的变量；如tcp_ack()函数中的packet_out（=0代表ACK过时或恶意），所有packet_out必须为0，且要用到总和去检验ACK；
Any TDN，TDTCP会尽早重传丢失片段在任意TDN；如果ca _ state为Loss或Recovery，且Loss _ out非零，则TDN优先重传丢失的段；
Specific TDN，当一段数据被确认接收，它们的追踪变量需要改变，在TDTCP中，通过扫描重传队列和获取TDN ID，去识别被确认的网段，改变特定TDN的变量；

RTT估计

计算得到的RTT有两类，一种是单个TDN的RTT，一种是跨TDN的RTT，这里倾向于得到各种TDN对应的RTT；

TCP本身有Karn-Partridge算法过滤重传数据包，TDTCP根据 DATA TDN和ACK TDN进一步过滤，将样本匹配到对应TDN；

重传计时器使用的timeout变量，保守设计为 $\over 2} RTT~n~$ + $\over 2} RTT~slowest$

五，开源代码

https://github.com/shuoshuc/TDTCP

环境配置

四台机器位于同一子网，三台主机用于发送/接受流量，一台交换机用于启动Etalon，四台均需要安装etalon和配置参数，三台主机需要安装TDTCP内核；

$ git clone https://github.com/shuoshuc/TDTCP.git
$ cd TDTCP
$ git submodule update --init --depth 1
//安装前更新初始化参数，包括三个网卡的信息、交换机、主机的FQDN
$ (open etalon_init.sh with your favorite editor)
$ (set the variables accordingly)
$ ./etalon_init.sh
//然后在每个主机上安装etalon
$ cd etalon
$ bin/install.sh “<one of host1/host2/host3/switch>” "yes"
//在三台host上安装内核
$ cd <path-to-TDTCP-root>
$ sudo ./install_kernels.sh

检查

//用swap脚本切换内核（不可行，改用修改开机设置时间进入高级选项切换内核）
$ cd <path-to-TDTCP-repo-root>
$ ./swap_kernel.sh <name-of-kernel>
//启动etalon，正常会出现持续打印的日志
$ /etalon/bin/click_startup.sh bw-lat

六，评估

etalon实验床

配置Etalon模拟小规模RDCN拓扑；（Etalon：新推出的RDCN模拟器，基于Click模式路由和DPDK）

在这里插入图片描述

模拟搭建了两个机架，每个机架16个host。实现：两个服务器运行16个Docker容器模拟一个机架的16台主机，一个服务器运行Ealon。（TDTCP是在实际Linux内核上运行，被模拟的只是网络本身。）

如图所示仿真了10Gbps的分组网络（电）和100Gbps的电路网络（光）；设置了TDN0为电网络，TDN1为光网络；带宽和平均RTT分别为：10Gbps/100us和100Gbps/40us；Etalon模拟了两个ToR输出队列（VOQ），大小设置为16个数据包；（测试平台使用40Gbps的硬件代替100Gbps，故使用时间膨胀，通过把时间延长20倍，用5Gbps物理网络容量模拟100Gbps网络）

在这里插入图片描述

优先光，无光则电； 流量为40秒长流；每个光TDN配置时间：180us，停电20us，7种MEMS配置组成一个周期。论文仅关注长流，因为短流很难从TDTCP获利。（非长流通过调整cwnd可以获得更好效果）

带宽和延迟差异

在这里插入图片描述

TDTCP明显优于CUBIC、DCTCP和MPTCP。唯一有竞争力的替代方案是reTCP，但它需要复杂的动态交换机缓冲区调整才能有效。

VOQ利用率可以反应拥挤程度，由于reTCP利用缓冲区做适配，所以这部分表现最差，而TDTCP表现最优。峰值是由于发送端起搏技术在切换到电TDN时候发了cwnd大小的包，帮助防止潜在的交换机缓冲区溢出。

重排序

在这里插入图片描述

TDN更改通知

在这里插入图片描述

ToR端数据包生成和主机端通知处理存在很大延迟，论文对其进行了优化，吞吐提升了12.7%，如图所示。

首先，ToRs可以使用缓存来最小化延迟：通过预先构造一个空的ICMP数据包并将其缓存在内存中。

其次，由原本的“push”模型（内核循环检查TDTCP流并更新他们的TDN ID）改为“pull”模型（每个TDTCP流在发送前检查TDN全局变量）。

最后，使用专用网络收发ICMP包。

Q&A

1，端口配置是根据流量，还是就是循环；

循环，即改进版Rotornet；

原文动机部分：“可预测的Tdn模式。OCS遵循由几个独立的配置组成的时间表，我们称之为天，其中每个独立的配置提供到ToR对的不相交子集的连通性。完整的时间表被称为一周。在两天之间，有一个停电期，我们称之为一个夜晚，在此期间，在光网络重新配置时，无法发送数据包。需求不敏感指的是配置是如何产生的[ 27 ]：完整的时间表在一周内提供完全网状连接连接，可以接受任何流量需求。”

原文评估部分：“我们测量各种TCP实现的长期跨机架流量吞吐量，作为TDN变化频率的函数；一个源机架中的所有16个主机将大量数据传输到目标机架中的相应主机。所有流均配置为同时启动并持续40秒**。我们部署了一个预先计算的静态调度（以RotorNet[30]的方式）**，该调度由180微秒长的配置组成。在每种配置中，机架要么通过OCS（即，TDN 1）直接彼此连接，要么通过分组交换网络（TDN 0）连接到所有其他机架。每个配置由20微秒的断电（重新配置）周期隔开。我们的实验侧重于分组与光TDN的比例为6:1的调度，这自然对应于8机架混合RDCN，其中每7个OCS配置中就有1个机架与其他机架直接连接。TDTCP比其他TCP变体具有最大的优势，其比率在这个顺序上。我们将研究TDTCP在极端比率下运行时的性能作为未来的工作。”

在这里插入图片描述