一、Overview

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

特性	classic	learning-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_{prev}$ 开始，classic CCA会在每个ACK时，改变速率；同时收集网络性能的统计数据，用于learning-based CCA的训练。（兼顾classic探测网络环境比较快，learning-based探测网络环境比较准的特点）

但何时退出该阶段呢？
在这里插入图片描述
由该图可以看到，当两种情况发送时，切换到下一阶段。
1.当两个候选速率的差值超过一个阈值时，切换。
即 $|x_{cl}-x_{rl}|\geq th_1$
2.当持续的时间超过设计值时，切换。
即 $t_1-t_0\geq th_2$

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

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

Exploitation Stage
使用速率 $x_{prev}$ 进行传输。并等待ACK，计算 $u(x_{cl})$ 和 $u(x_{rl})$ 。
其中utility function沿用了PCC的：
$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$

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

五、RL-based CCA算法

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

动作空间：
AIAD or MIMD