Libra论文阅读笔记-A unified congestion control framework for diverse application


论文题目:《A unified congestion control framework for diverse application preferences and network conditions》
CoNEXT’21


一、Overview

目前的拥塞控制算法(CCAs)可以分为传统(classic) 拥塞控制算法和基于学习(learning-based) 的拥塞控制算法。
传统的拥塞控制算法的设计理念都是指定特殊的现象对应特殊的规则,即hard-wired mapping。而基于学习的拥塞控制算法具有更好的适应性(Adaptability)灵活性(Flexibility),但实用性(Practicality) 较差。

特性classiclearning-based
Adaptability
Flexibility
Practicality

本文提出Libra拥塞控制框架,希望集classic和learning-based的优点于一身。

二、问题背景

下面围绕三个特性进行讨论:适应性(Adaptability)灵活性(Flexibility),但实用性(Practicality)

  • Limitation on adaptation
    将不同的CCA算法在Wired和LTE网络下测试——现有的CCA无法适应不同的网络环境。(这其实是通病,没有任何一个算法可以在所有情况下达到最好,都是一个trade-off)

  • Limitation on flexibility
    Classic算法无法应对不同的性能偏好做出调整(the hardwired mapping between predefined events and actions makes the classic CCAs hard to be tuned)

  • Limitation on practicality
    目前除了PCC应该还没有其他的learning-based的算法被部署到实际系统上,特别是这些基于DL和RL的。并且已经部署测试的PCC,效果也并不是很好。

三、Libra方案overview

Libra使用了类似与PCC的utility function来描述不同发送速率对应的网络性能。
Libra包括三个阶段:探索阶段exploration stage、评估阶段evaluation stage、利用阶段exploitation stage
在这里插入图片描述
三个阶段循环周期执行,其中winner sending rate,即绿线,是来自于上一个循环的决策速率。
其中红色、紫色、绿色线分别代表classic sending rate、learning-based sending rate以及上一轮的winner sending rate。
实线代表的是目前Libra应用的速率。在第一个阶段探测阶段中,使用的是classic sending rate。

执行流程:Libra会在上一轮循环中,得到一个winner速率,在exploration stage阶段下,classic方案以该速率作为基础,得到classic sending rate,并且以该速率作为该阶段的发送速率。(同时在该阶段下,会得到classic和learning-based两种方案的发送速率)
在evaluation stage下,逐一评估这两种速率的utility。在最后的exploitation stage,使用上一轮的winner sending rate,同时接收evaluation stage发送的包。在这一阶段中,得到classic和learning-based两个速率对应的utility,决策出一个winner sending rate作下一轮循环使用。

对于没收到ACK的处理方案:
在exploration stage没收到ACK时,保持learning-based的发送速率,并跳过相应的action。如果在其他stage没收到ACK,则直接使用当前的winner sending rate接着进入下个循环。

四、Libra方案设计

  • Exploration Stage
    在该阶段下,从速率 x p r e v x_{prev} xprev开始,classic CCA会在每个ACK时,改变速率;同时收集网络性能的统计数据,用于learning-based CCA的训练。(兼顾classic探测网络环境比较快,learning-based探测网络环境比较准的特点)

但何时退出该阶段呢?
在这里插入图片描述
由该图可以看到,当两种情况发送时,切换到下一阶段。
1.当两个候选速率的差值超过一个阈值时,切换。
∣ x c l − x r l ∣ ≥ t h 1 |x_{cl}-x_{rl}|\geq th_1 xclxrlth1
2.当持续的时间超过设计值时,切换。
t 1 − t 0 ≥ t h 2 t_1-t_0\geq th_2 t1t0th2

  • Evaluation Stage
    在该阶段下,不再计算classic和learning-based速率,减少了一部分计算开销。测试上一阶段得到的两个候选速率对应的utility function, u ( x c l ) u(x_{cl}) u(xcl) u ( x r l ) u(x_{rl}) u(xrl)——这两个要在下一个阶段才能计算出来。paper中指出,可以在这个阶段得到 u ( x p r e v ) u(x_{prev}) u(xprev),但在上一个阶段中,使用的是classic sending rate,好像是算不出来吧(都没有用这个 x p r e v x_{prev} xprev速率传输)。这里表示疑问?

这里对于评估速率的顺序有一点讲究!
先说结论:lower rate first。即先测试低的速率,减少副作用。
在这里插入图片描述
看第一个图,假设 x c l > x r l x_{cl}>x_{rl} xcl>xrl,先测试大的速率,会带来buffer累积,影响后面速率的测试,在这种测试顺序下, u ( x c l ) > u ( x r l ) u(x_{cl})>u(x_{rl}) u(xcl)>u(xrl),但实际上是 x r l x_{rl} xrl更好。后面的情况类似,因此lower rate first。

  • Exploitation Stage
    使用速率 x p r e v x_{prev} xprev进行传输。并等待ACK,计算 u ( x c l ) u(x_{cl}) u(xcl) u ( x r l ) u(x_{rl}) u(xrl)
    其中utility function沿用了PCC的:
    u ( x i ) = α ⋅ x i t − β ⋅ x i ⋅ max ⁡ { 0 , d ( R T T i ) d t } − γ ⋅ x i ⋅ L u\left(x_i\right)=\alpha \cdot x_i^t-\beta \cdot x_i \cdot \max \left\{0, \frac{d\left(R T T_i\right)}{d t}\right\}-\gamma \cdot x_i \cdot L u(xi)=αxitβximax{0,dtd(RTTi)}γxiL

算法:
在这里插入图片描述
这里基本就是把前面的三个流程程序化写出来。

五、RL-based CCA算法

这里介绍的是上面算法里面第6行的DRL_based CCA。
作者通过比较多的对比实验,去看各种状态空间和动作空间对结果Reward和收敛性的影响,自行设计了状态空间和动作空间。
状态空间:
在这里插入图片描述
这是paper里总结出来的目前的状态空间。 作者提到模拟退火来辅助产生baseline状态空间,具体操作没详细描述,这里实验设计并不是很清晰。
在这里插入图片描述
动作空间:
AIAD or MIMD
在这里插入图片描述

Reward Function
两个observation:
1.奖励函数还是要考虑loss rate,不然在高延迟下,容易引起高丢包率。
在这里插入图片描述

2.选择 r r r还是 Δ r \Delta r Δr作为奖励函数:
在这里插入图片描述
Δ r \Delta r Δr更好。这里的reward function和前面的utility function并不一样。
在这里插入图片描述

总结

这个混合传统算法和learning算法的框架挺有趣的,并具备了在线评估的特点,但文章代码无开源,有些具体的细节还是不太理解。文章中仍然用到了DRL的内容,这块不是很熟悉,对于如何设计状态空间和动作空间的实验不太清楚。
文章提出的这种结合的框架,还是挺新颖的。

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值