从Owl到smartCC再到DeepCC：数据驱动的传输协议优化
前言
Owl: Congestion Control with Partially Invisible Networks via Reinforcement Learning
SmartCC: A Reinforcement Learning Approach for Multipath TCP Congestion Control in Heterogeneous Networks
DeepCC: Multi-Agent Deep Reinforcement Learning Congestion Control for Multi-Path TCP Based on Self-Attention
三篇论文，他们都围绕了一个主题，强化学习赋能拥塞控制问题。第一篇是21年infocom，单智能体深度强化学习做单路经拥塞控制，第二篇是19年SCI 一区TOP，单智能体强化学习做多路径拥塞控制，第三篇是21年的 SCI 二区的一篇， 多智能体深度强化学习做多路径拥塞控制
作者介绍
第一篇作者是都灵理工的教授，他的主要研究是分布式系统安全策略，他近几年的工作与拥塞控制/人工智能这些方向相关性其实不是很强，所以这里不做具体介绍
第二篇的作者是南京大学的李文中老师，一作是他的博士。这位老师主要研究方向是分布式计算，智能化网络等，近三年来 他为一作的文章，主要是人工智能方法与拥塞控制资源调度相关。基本是一区二区。
第三篇来自北邮的网络与交换技术国家重点实验室-网络智能研究中心的 王敬宇，戚琦老师，近三年来的主要是智能网络，AI驱动的一些资源分配调度问题，以及一些非网络场景的AI的研究。三年内有很多ccfA的成果。
三篇研究共性
近几年，随着AI技术的研究发展，网络协议和RL结合也变成了一个方向。在读相关领域文献的时候，会发现，大家关注的场景大多数情况下是无线网络，移动网络这类资源受限的网络，以及高动态性的网络，比如火车接入网路，卫星网络：
究其原因，一方面是，这些场景具有动态性，但是传统的基于规则的启发式算法很难有动态调整的能力。另一方面是由于在质量较好的网络中，现有的启发式算法的效果已经非常好了，在一篇21年的sci3区的综述性文章中，他们对之前的所有的主要的调度算法和主流的拥塞算法进行组合实验研究，结果发现，网络环境比较好的时候，启发式算法改进带来的效果已经很小了。在方向展望中，他们认为未来拥塞和调度研究主要要在两个角度：1是对于网络状态的感知能力，（中科大一篇顶会，共享瓶颈链路感知的BBR算法）2，另一个是元调度能力（这点21年sigcom阿里的xlink，[mpquic的拥塞和调度算法是可以很灵活的配置的] 他们在寻求根据网络场景进行拥塞调度算法灵活切换的能力）
第一篇 Owl: Congestion Control with Partially Invisible Networks via Reinforcement Learning
这篇文章的研究角度主要是针对无线网络等环境这类需要动态调整能力的网络，旨在利用强化学习来进行拥塞控制。他和已有的一些RL拥塞算法的区别在于：他们的状态空间不单单是传输层参数，还引入网络层级的信息作为模型的状态空间，而且这个方法不需要开启显式拥塞通知，也不需要修改包。
接下里看他的模型，他们是用dqn算法（深度强化学习）。动作空间简单的取了-10到10这么一个加性调整空间。奖励函数是综合了考虑丢包率和吞吐量来约束。整个算法流程，智能体和环境交互获取状态空间，然后智能体根据状态和上步的奖励进行学习和预测下一步要采取的动作，选择拥塞窗口的调整参数。
这篇文章的一个重点是他们引入了网络层级的参数作为状态空间。整个状态空间的采样是1s一次，传输层的数据，自己实现了一个用户层和内核层的交互接口来获取数据。网络层面的数据是两个，一个是PNK，这个参数是传输链路上的流过每个交换机两端的流量差中的最大值，来表征链路的情况，另一个是由于网络中有些设备可能统计不到，所以会计算一个被统计设备的百分比。整个实验网络是基于SDN的网络，在控制器进行统计之后，通过restful API暴露给部署在端点的智能体上。
实验分为两部分：一部分是mininet做的仿真，另一个是GENI testbed(查询不可用)的一个真实网络仿真。
第二篇 SmartCC: A Reinforcement Learning Approach for Multipath TCP Congestion Control in Heterogeneous Networks
这篇文章的研究角度是 异质网络场景的多路径传输，比如WIFI和LTE网络，各个链路的延迟，带宽，丢包等都不一样，基于规则的固定策略下，mptcp多子流会有缓冲区膨胀的问题和子流饥饿问题。
三个点：首先多子流场景下，需要考虑协同传输问题，即同时考虑多条路径的情况进行拥塞控制。其次是多子流场景中，随着子流数的增加，模型的状态空间会指数级增长，需要考虑状态空间的问题；其三也是本文着重考虑的此方法在真实网络如何部署的问题。
我们首先看一下他整个模型的结构，该文设计一个异步的学习结构，分成了离线训练和在线预测两部分，算法采用的是qlearning(基于性能考虑，没有选择深度算法)。运行的过程中，智能体会和环境交互进行数据收集并存到离线算法部分的经验复用池，离线部分进行学习，更新参数，定期同步到在线决策部分。在本文中，为了加快训练收敛，会在在算法启动阶段，先利用启发式算法进行先验训练(有点像DRL领域的课程学习)。具体操作是如果输入stage未知，则按照LIA算法动作，如果stage已有，则按照贪心策略进行动作选择。
我们看一下这篇文章的状态空间，他设计了两个参数来表征每条子流，I和R，I由上一次的I和本次两个ACK的时间间隔差来组成，表征子流的延迟和可用带宽的变化，R表征子流i相对于整体的相对发送速率。由于用的是qlearning，采样需要将状态空间映射到离散空间，这里用softmax改进了瓦片编码实现。
动作空间设计了线性的公式来约束，用两个离散值u和v来组合实现不同的拥塞调节窗口大小。本质是实现了传统TCP拥塞算法AIMD的动作的超集，引入了乘性增和线性减。但是乘性空间在传统的算法会带来不公平。但是这个点对于基于学习的算法可能不是问题，而且会带来更快的反应速度。
实验是采用了ns3中的一个mptcp开源实现，在图里这个拓扑中进行训练，先把模型放到各自网络场景进行训练，然后将智能体放到异质网路中测试。
第三篇 DeepCC: Multi-Agent Deep Reinforcement Learning Congestion Control for Multi-Path TCP Based on Self-Attention
第三篇是一个多智能体做多路径拥塞控制算法问题
首先分析已有算法的不足，1.是上篇论文那种单智能体做多路径拥塞控制，一个智能体同时控制多条子流，性能比较差，控制粒度比较粗糙。 2. 每次训练一个模型，他的状态空间是固定的，子流数变化，模型就需要重新训练，3. 单智能体综合考虑整体，会忽视单流的性能最大化。
针对以上三个问题：1. 引入了多智能体深度强化学习，多智能体深度强化学习通俗讲就是多个单智能体算法利用博弈论串起来。2. 状态空间的问题，引入子注意力机制处理输入状态。状态空间向量由两个部分组成，一部分是当前子流的状态向量，另一部分是其他子流的聚合。3. 给每个智能体的神经网络里面加了一个自注意力层，设计了一个新的奖励函数来平衡单流和整体效能。
deepCC也采用异步设计，但是他这个图画的有问题，其实和上一篇一样，他也是在线决策跑一个模型，训练跑一个模型。
deepCC通过sysctl和系统调用实现与内核层的数据交互，数据采样发生在是每次包被调度的时候。
下面讲一下他这个算法模型：每个子流由一个独立的智能体控制，该智能体的状态空间由自己流的状态向量+自注意力机制实现的其他流状态向量 组成。参数选择了 吞吐量，发送速率，RTT等参数。
动作空间：控制两个部分：1.是对拥塞窗口的乘性调节 2.是加性的对分离速率的调节。
奖励函数这块，他的目标是追求总目标最优的情况下，各子流的收益也能尽可能最大化。或者奖励函数的第一部分是当前流的平均带宽减去β倍的丢包率，第二个参数是剩下的流的参数。α用来权衡这个平衡。
他的DRL算法选择的是MAPOKTR，一种比较新的AC算法。看图，其他子流过一个双向的lstm提取到特征后，输入到子注意力层进行聚合，然后和当前流的向量进行自注意力的聚合。
实验部分，采用的是物理机搭建网络，拓扑如图，多对一场景。结果的话，吞吐量和抖动表现都比之前的方法要好。
这篇文章的公平性有问题。一来全文没有分析，这种拥塞算法下和其他tcp流共用瓶颈链路的时候，是否对其他流公平，而来他的公平性分析是放到了子流之间流量分配的公平。
4月30日加注：
在后续阅读相关研究方向的文章，BLEST(异质多路径调度算法),AURORA(强化学习单路经网络拥塞)和MPCC(多路径版本PCC)的过程中。发现3月份后两篇文章存在一些问题：
- 状态空间的采集，（1）.数据采集应该采用时间段的形式来，（2）多路径传输中，各链路Rtt不同，所以各子流的数据的数据采集时间间隔应该是不相同的
- 多路径拥塞问题是应该和调度问题放到一起考虑的
- 调节发送速率的动作形式不适合多路径传输
- 多路径传输中并不是每条链路都要选择的(虽然是一个调度问题，但是反应到拥塞上，多子流的选择问题也会直接影响拥塞调节)。做多路径拥塞研究，不应该只考虑每条子流的rtt，还要考虑整体传输任务的rtt，和调度配合起来。
- DeepCC的一个比较严重的问题是，他认为子流之间要相对公平的分配流量，这一点在BLEST这篇文章中分析的比较明白，真实情况不光不应该追求各流的任务公平，甚至并不是每条流都应该被使用。异质严重的网络中会引发很严重的拥塞问题以及性能下降。
- deep CC和SmartCC的考虑的拓扑有点简单，结果说服力不强。DeepCC实验存在没有做出来的嫌疑，因为按照其他顶会文章的分析，这篇文章的方法有些方面是违背了一些网络优化的准则的，应该不会取得很好的效果。(比如按照调度数据包的级别去计算状态统计，这一点是大家共识实现不了的。引入了很复杂的神经网络，计算开销比其他文章的简单网络要大，但是他们的动作比其他简单网络还要密集。网络的延迟奖励，在文章是没有考虑的。这一点在其他工作中证明，RL是学不到东西的)
