当前位置: 首页 > news >正文

论文分享:PowerTCP: Pushing the Performance Limits of Datacenter Networks

1 原论文的题目(中英文)、题目中包含了哪些关键词?这些关键词的相关知识分别是什么?

题目:PowerTCP: Pushing the Performance Limits of Datacenter Networks

      PowerTCP:逼近数据中心的网络性能极限

2 论文的背景:作者、工作单位、发表刊物、索引情况

作者:Vamsi Addanki 、Oliver Michel 、Stefan Schmid

单位:TU Berlin 、University of Vienna、Princeton University

发表刊物:19th USENIX Symposium on Networked Systems Design and Implementation(NSDI2022 计算机网络CCF A类)

3 问题的提出:论文论述的技术/科学是什么问题?为什么会存在这样问题?这种技术/科学问题存在的背景是什么?

本文研究的是数据中心网络的拥塞控制算法

背景知识:

数据中心中存在三种形式的流:查询流、短流、长流。其中查询流和短流对延迟敏感,长流需要较高的吞吐量。

数据中心对网络的要求:低延迟、高带宽。

常规的TCP协议的拥塞控制机制(慢开始、拥塞避免、快重传、快恢复)不再适用于数据中心网络环境。

4 问题的相关研究:其他相关研究是如何解决类似的问题的?

现有的对数据中心网络拥塞控制的研究主要分为两类:基于网络状态的拥塞控制算法和基于网络变化的拥塞控制算法。

4.1 基于网络状态的拥塞控制算法

根据交换机中 Queue Length 或者RTT来发现拥塞,并且依据这些信息决定该如何调整拥塞窗口的大小(cwnd)。(voltage based)

以DCTCP(Data Center TCP)为例。在交换机处设置阈值 K,数据包达到交换机时,若队列占用值大于K,则标记该数据包。接受端收到带有标记的数据包后返回的ack报文同样带有标记,发送根据收到的ack中带标记的数据包占总发送数据包的比例来调节拥塞窗口大小(cwnd)。

实例:DCTP、DCQCN、HPCC

优点:控制更加准确

缺点:反应较慢(针对突发的网络冲突应对不足)

4.2 基于网络变化的拥塞控制算法

根据交换机中网络变化,比如检测RTT的变化(RTT的梯度),并且依据这些信息决定该如何调整拥塞窗口的大小(cwnd)。(current based)

实例:TIMELY

优点:反应更快

缺点:控制不太精准

4.3 两种拥塞控制算法的问题

由于当前的网络拥塞控制算法(Congestion Control,简称CC)实现原理的限制,当前CC在反应速度和控制精度上往往只能选一个。 

(a) 当队列长度增长速度发生变化时,基于网络状态的拥塞控制算法的反应是一样的。

(b) 针对于队列长度不同的设备,基于网络变化的拥塞控制算法的反应是一样的。

(c) 因此,基于网络状态的拥塞控制算法无法区分case2和case3这两种情形;基于网络变化的拥塞控制算法无法区分case1和case3这两种情形。

5 基本思想:本文解决该问题的基本思想、过程是什么?

实现网络拥塞控制需要如下两个关键点:

  • 如何发现拥塞
  • 如何控制拥塞

5.1 如何发现拥塞

本文使用的是带内网络遥测(In- band network telemetry ,简称INT)

带内网络遥测原理:

In-band:监测网络设备的状态时无需单独构造一个数据包,可以将检测信息附加到正常数据包(如TCP、UDP)的包头。(个人理解)

简单的来说,INT可分为两部分:INT Header和INT Metadata

  • INT Header:由INT的发送端添加进正常数据包,指明了要收集那些信息以及INT最终的接受端是谁。
  • INT Metadata:记录网络状态,由数据包传输过程中每个网络设备添加(交换机或路由),将需要检测的数据添加进来。 

本文的所使用的网络监测方法简介

要监测的信息:

  • Queue Length (qlen)
  • Timestamp (ts)
  • So far transmitted bytes (txBytes)
  • Bandwidth (b)

监测流程:

表示正常数据包

表示INT Header

表示确认收到的ACK 

Sender :-->网络设备--->--->Receiver

Sender :<-----网络设备<----<-----Receiver

5.2 如何控制拥塞

几乎所有的拥塞控制都是通过控制发送端的拥塞窗口的大小(cwnd

具体拥塞窗口该选多大是根据拥塞控制算法算出的。

本文就提出了PowerTCP算法,是一种同时基于网络状态和网络变化的拥塞控制算法。

6 配图:找出全文中最具概括性的一幅配图(架构图/流程图/思路图...),简单解释这张图。这幅图是如何概括全文的?

网络拥塞程度

 \underbrace{\Gamma(t)}_{power}=\underbrace{(q(t)+b\cdot\tau)}_{voltage}\cdot\underbrace{\lambda(t-t^f)}_{current}

\Gamma(t) :反应当前网络的拥塞程度

q(t): 当前队列长度

b: 带宽×基本往返时间(不包括排队延迟),飞行中的数据量。

\lambda(t-t^f):队列长度变化率

计算拥塞窗口的公式

w_i\leftarrow \gamma(w_i(t-\theta(t)))+(1-\gamma)\cdot w_i(t)

e=b^2\cdot\tau; f(t)=\Gamma(t-\theta(t)+t^f))

 w_i(t):拥塞窗口大小

 \gamma:经验参数,建议取0.9

 \theta(t)=\frac{q(t)}{b}+\tau:基本往返时间(Base RTT) +排队延迟

 \beta:增量,经验参数

计算拥塞窗口的算法

7 实验:采用了什么硬件配置和软件环境?每项测试是在和哪些同类研究做对比?分别测试了哪些指标(例如,延迟/吞吐量/资源利用率...)?

环境:

 搭建了一个基于Fat Tree拓扑的数据中心网络,其中有2个核心交换机和256台服务器,它们被组织成4个pod。每个pod由两个ToR交换机和两个汇聚交换机组成。所有交换机到交换机链路的容量均为100Gbps,服务器到交换机链路的容量均为25Gbps。

测量指标: 吞吐量、队列长度、尾延迟、短流的99th-percentile flow completion times (FCT),不同大小的流的 99th-percentile FCT。

8 二次利用:论文是否提供源代码?

无;

其他开源项目:DCTCP、HPCC、TIMELY

http://www.lryc.cn/news/99324.html

相关文章:

  • 浏览器的同源策略 - 跨域问题
  • go 查询采购单设备事项[小示例]V2-两种模式{严格,包含模式}
  • c++11 标准模板(STL)(std::basic_filebuf)(八)
  • 行为型模式之解释器模式
  • 阿里云域名备案
  • Clion开发Stm32之温湿度传感器(DS18B20)驱动编写和测试
  • 文档管理NAS储存安全吗?
  • 用windeployqt.exe打包Qt代码
  • 【Python机器学习】实验04(2) 机器学习应用实践--手动调参
  • 【爬虫案例】用Python爬取iPhone14的电商平台评论
  • 01)docker学习 centos7离线安装docker
  • 前端 - 实习两个星期总结
  • MySQL——主从复制
  • 报表下载工具
  • 树及其遍历
  • Qt报错解决办法
  • Python(四十七)列表对象的创建
  • #systemverilog# 说说Systemverilog中《automatic》那些事儿
  • C/C++ 动态内存分配与它的指针变量
  • UE5初学者快速入门教程
  • 论文笔记--FEDERATED LEARNING: STRATEGIES FOR IMPROVING COMMUNICATION EFFICIENCY
  • STM32MP157驱动开发——按键驱动(异步通知)
  • 医疗器械维修工程师心得
  • Vue3 Radio单选切换展示不同内容
  • FreeRTOS之二值信号量
  • ChatGPT API进阶调用指南
  • 人工智能术语翻译(四)
  • kubernetes持久化存储卷
  • 【Rust笔记】意译解构 Object Safety for trait
  • Spring Boot单元测试入门指南