本文提出并研究了深度强化学习 (RL) 的一个新的及时的应用领域:互联网拥塞控制。拥塞控制是调节流量源数据传输速率以有效利用网络容量的核心网络任务。随着网络直播、虚拟现实和万物互联等网络服务的出现,拥塞控制越来越收到广泛关注。我们研究表明,将拥塞控制作为RL可以训练深度网络策略,捕捉数据流量和网络条件中的复杂模式,利用这一点超越了最先进的拥塞控制技术。我们也强调了真实世界采用基于强化学习的拥塞控制算法面临的重要挑战,包括公平性、安全性和普遍性等问题,这些问题在传统的 RL 形式主义中并不容易解决。为了便于进一步的研究和结果的可重复性,我们提出了一个基于 OpenAI Gym 接口的 RL 指导的拥塞控制测试套件。
作者:Nathan Jay, Noga Rotman, Brighten Godfrey, Michael Schapira, Aviv Tamar
来源:PMLR 2019
论文题目:A Deep Reinforcement Learning Perspective on Internet Congestion Control
论文链接: https://proceedings.mlr.press/v97/jay19a.html
源码:https://github.com/PCCproject/PCC-RL
内容整理:李冰奇
第一部分——引言
随着在真实世界决策策略上的应用,深度强化学习持续受到追捧,通过促进蛋白质折叠等复杂任务(R.Evans, 2018)和在围棋等具有挑战性的环境中击败人类专家(Silver等人,2016年)而成为头条新闻。我们希望利用深度强化学习 DRL 的优点解决现存重要的网络拥塞控制问题。
网络拥塞控制
在如今互联网上,大量的网络用户竞争稀缺的通信资源。因此,各种流量源必须动态调整数据传输速率以高效利用网络资源,提供好的用户体验。这一挑战被称作“拥塞控制”( CC ),CC 是计算机网络研究和实践的基本。确实,CC 对用户体验至关重要,尤其是对视频流和音频流,以及正在逐渐兴起的增强现实、虚拟现实、物联网、边缘计算等互联网服务。
考虑图 1 的示例所描述的,多连接(也被称作“流”)共享一条通信链路。每一个连接都有一个流量发送方和一个流量接收方,发送者把数据流发送给接收端,并持续接收接收端发送的反馈信息(ACKs),并根据反馈调整发送速率。发送端调整发送速率的方法取决于连接双方采用的拥塞控制协议。不同连接的收发双方的交互产生网络动态变化,取决于相互的拥塞控制协议,链路容量(带宽),以及链路缓存大小和包排队策略,决定了哪些多余的流量被舍弃。及时是图 1 这种简单的单链路场景也描述了拥塞控制的复杂性,在这个场景中,不同的连接链路选择发送速率也是不协调,难以集中调整的。通常,每一条链路都没有竞争链路的明确信息,比如数量、进出网络的次数、采用的拥塞控制协议等,或者整个网络的明确信息,比如网络带宽、缓存大小、数据包排队策略。当然,当流量通过多个链路转发时,这些挑战会加剧。
基于 RL 的拥塞控制的研究动机
我们认为在拥塞控制的背景下研究 RL 有两个重要的方面:(1)提高互联网通信基础中至关重要的部分的性能,这可能会影响使用者的使用体验,尤其是对体验敏感的互联网应用;(2)提供 RL 机制一个令人兴奋的新的平台,提出了一个新的面向真实世界动机的研究方向。一种拥塞控制协议可以被认为是把从收端得到的历史反馈信息,这些信息反映了过去的流量和网络状况,来指导下一步的发送速率。我们假设本地的历史信息里包含了流量模型和网络状况,我们可以通过强化学习来从这些经验中学习这些映射关系,这可以被很好的利用去做速率选择。这一假设受到近期强化学习在各种领域抽取有用特征的成功的激励,包括图像、声音和游戏领域等的成功。通过下面两个例子,说明 RL 机制可以学习的模型的类型:
区分非拥塞丢包和拥塞丢包
丢包可以被分为不同的现象引起的(Dong et al., 2015; Cardwell et al., 2016; Dong et al., 2018);一些丢包可能是由于拥塞,比如,超过网络容量,然而其他丢包可能不是拥塞相关的丢包,例如,由于移动基站切换引起的丢包。现在非常流行的 TCP 协议有一个出名的缺点就是这一协议天然的没有能力区分拥塞丢包和非拥塞丢包,这导致 TCP 的速率控制是追求次优的(Dong et al. 2015)。
图 2 描述了一个 30 Mbps 带宽的连接上,随机 1% 的丢包,只有一条数据流的情况下,一种使用 Linux 系统默认的 CUBIC 协议,一种情况使用我们设计的 RL 框架,两种协议下链路吞吐量情况。观察到,TCP CUBIC 协议下,每当发生丢包,发送端就会将发送速率减半,这样就不能完全利用链路带宽。然而,基于 RL 的协议有效的区分两种类型的丢包。当发生随机丢包的情况下,增加发送速率,但是,当由于发送拥塞引起丢包的情况下,通过不增加速率又避免超过链路容量太多。因此,基于 RL 的拥塞控制协议能够维持较高的链路利用率。直观上来说,两种类型的丢包是能够区分出来的,因为随机丢包不是发送端行为引起的,但是拥塞丢包速率会随着发送速率增加而增加。
适应多变的网络状况
网络状况,例如可获得的链路容量,丢包率和端到端延迟,随着时间动态变化很大(e.g., in mobile/cellular networks, Winstein et al. 2013)。TCP 在多变的网络状况下表现很差。(Dong et al., 2015; Cardwell et al., 2016; Dong et al., 2018; Arun & Balakrishnan, 2018)。假设只有一条数据流,链路容量在 20 Mbps 和 40 Mbps 之间每 5 秒切换一次(链路没有随机丢包)。理想情况下,拥塞控制协议应该调整发送速率使得速率更好匹配链路带宽,像在图 3 黑的虚线描述的,这样,充分利用带宽又没有引起拥塞。
向图 3 展示的, TCP CUBIC 没有做到这一点。相比而言,基于我们 RL 框架的拥塞控制协议更接近理想的行为。直观来看,这一协议学到了网路状况的变化,例如,突然陡峭的丢包表明可用带宽下降很快,发 送速率超过 20 Mbps,并没有丢包表明可用带宽更高(40 Mbps)。
我们的贡献
我们提出了一种基于 RL 的拥塞控制协议设计的新框架,这种框架扩展了最近介绍的面向性能的拥塞控制方法( PCC )(Dong et al., 2015; 2018)。我们讨论将拥塞控制作为 RL 任务的挑战。我们也说明了现实世界采用基于 RL 的拥塞控制机制面临的挑战,例如公平性,安全性和普遍性问题,这些在传统的 RL 形式中是很重要去解决的。我们利用我们的框架设计了 Aurora。Aurora 采用深度强化学习(Sutton et al., 1998; Schulman et al., 2015),来产生一条策略,用来把观察到的网络统计数据(例如延迟,吞吐量)和发送速率选择匹配起来。我们初步的评估结果表明在简单、模拟的环境中训练 Aurora 也是足够能够产生在非常不同的为网络中表现也很好的拥塞控制策略,这些策略比得上或者超过最先进的人为设计的协议。
第二部分——网络拥塞控制中的 RL 方法
我们接下来提供 RL 的高级概述,并解释拥塞控制怎么被制定为 RL 任务。
背景:强化学习
拥塞控制作为 RL 研究领域
我们把拥塞控制当作 RL 框架下一系列的决策问题。行动 Action 是调整发送速率。在我们的模型中,智能体就是数据流的发送端,智能体的动作就是个改变发送速率。为了建模这一问题,我们采用 MIs (间隔时间段监督)(Dong et al., 2015;2018)的概念。时间被分成连续的时间间隔,在每一个监督间隔段的开始,发送端调整一次它的发送速率 xt,这一发送速率在接下来的时间间隔里保持不变,在尝试了几个选项之后,我们把改变当前的发送速率作为行动 Actions。
状态 State 和网络状态的历史统计数据绑定。发送端在 MIt 里选择发送速率之后,将观察到在这个发送速率的后果,并且从收到的 ACKs 中计算统计空间 vt,我们把我们的统计空间限制在以下组成部分:(i)延迟梯度(Dong et al., 2018),即延迟对时间的倒数;(ii)延迟比率latency ratio (Winstein& Balakrishnan, 2013),即当前监督时间段内的延迟和观测到的历史监督段内最小的延迟的比率;(iii)发送率,即发送的数据包和确认接收的数据包的比率。
网络在可用带宽,延迟和丢包率方面变化很大。我们选择统计空间组成元素是为了提高我们模型的普遍性,避免由于链路属性的变化(比如链路延迟,单位毫秒)而造成统计空间数据高度变化。
设置奖励。在特定的时间特定的发送速率所能获得的奖励取决于对于特定应用程序的要求所表现的性能;例如在线游戏等一些应用程序可能要求非常低的时延,然而,另外一些应用程序例如大文件的传送,可能更高的带宽更重要;有一些服务应用可能需要低但是持续稳定的带宽(没有网络抖动),然而其他的应用可能更喜欢大带宽并且能够容忍网络变化。我们在 3.1 节讨论特定的奖励函数。一个行动(发送速率变化)的效果可能不会立即产生后果,例如,发送节奏太快引起缓存溢出,可能导致将来时段的丢包和延迟。在 RL 中,长远决策的制定可能通过折扣因子 γ 来获得。我们将在 3.3 节讨论我们框架中 γ 的影响。
其他考虑的方法
在提出本文这个方法之前,我们考虑了把拥塞控制的可选模式和可选的模型结构(包括线性模型)作为学习的任务(最著名的 bandits problem),我们的结果(见图 5 )表明学习一个合理的策略,折扣因子 γ 不能太低(例如,γ 至少是 0.5 ),折扣因子越大(γ=0.09 )学习速度更快。这个和任务的顺行本性是一致的。在这个任务中,奖励可能延迟,这是因为有限的链路缓存大县的影响,并且随着链路占有的增加延迟也会增加。此外,训练线性模型的表现比单层神经网络差得多。我们还尝试了简单的随机搜索和线性模型的爬坡,最近(Mania等人,2018)表明,它在连续 Mujoco 任务上表现良好,但这些在我们的上下文中没有竞争力。在我们的实验部分(第 4 节),0.99 的折扣因子导致更快的学习(尽管最终的学习效果和 γ = 0.5 差不多,见图 5 ),这表明延迟的奖励作为更强的信号是很重要的。
第三部分——介绍 Aurora
在这一部分我们将介绍 Aurora:一种专门的拥塞控制 RL 实现方法,基于上面的公式模型,取得了最先进的结果。我们的代码可以在我们 github 仓库下载得到。
结构
RL 的输入和输出。我们选择下面的公式作为我们 “agent” 基于第 2 节讨论的数据集产生的输出和发送速率 X t-1的变化之间的映射关系:
其中 α 是用来抑制波动的标量(在这里我们取值 α = 0.025)。#神经网络。神经网络架构变化很大,研究表明新架构也是以难以置信的速度出现,因此选择最佳架构是不切实际的。但是,我们发现即使是最简单的架构,例如小的完全连接的神经网络,也能够产生好的结果。我们测试了隐藏层数量和每一层神经元数量的几种选项,之后我们选择了包含两层隐藏层包含32->16个神经元和双曲正切非线性的结构。每一个结构重复训练三次,这一结构获得最高的平均训练奖励,并且通过我们的评估过程,展现高的性能表现(见图 4 )。#奖励函数。我们用线性的奖励函数训练 Aurora ,奖励吞吐量惩罚丢包和延迟。最新的 PCC-Vivace (Dong et al., 2018)和 Copa (Arun & Balakrishnan, 2018)算法尝试使用不同的指数和对数优化这些组件的奖励函数,但是目标相似(高吞吐量,低延迟,pc – vivace也会惩罚损失)。我们提出下面的线性函数:
其中,throughput吞吐量表示每秒的数据包,latency 单位是秒,loss 丢包表示发送但是未确认的比率。选择每个因素的范围使得模型平衡我们选择的训练参数的吞吐量和延迟。在第 4 节里,我们讨论其他算法的目标函数(或者缺乏目标函数),说明 Aurora 的吞吐量和延迟的折中。
训练
我们在开源的 gym 环境中训练我们的智能体,在第 5 节里详细解释,这一环境模拟了一系列参数的网络连接。我们的模型使用 PPO 算法进行训练(Schulman et al., 2017),基于稳定基准的 python 包实现的。(based on Dhariwal et al. 2017)。
参数选择
尽管许多参数影响我们最终模型的质量,但是我们接下来讨论两个重要的参数选择:历史数据的长度和折扣因子。#历史长度。历史长度 k 意味着智能体基于 K 个最近的 MI 监督时间间隔有价值的数据作出决定。直观上来说,增加历史时间长度应该增加性能表现,因为提供了额外的信息。我们用 [1,10MIs]范围的 k 来训练模型,图 4 展示了这些训练模型的奖励获得情况。
最终结果显示,k=2 和 k=10 训练的模型获得的奖励结果相差不多,但是 k=1 只有一个监督时间的历史数据在我们选择的训练集得到的结果就要差很多。
#折扣因子。我们测试了三个不同的 γ 取值,最终决定,γ = 0.09 能够快速取得最好的结果,然而当γ=0.50最终也能学到合适的策略,γ=0.00时模型学习不到有用的策略。考虑到采取行动和观察到奖励之间的间隔,这个结果看起来就很直观。图 5 展示了这一趋势。
第四部分——评价
我们的训练框架使用具有不同参数的网络链路上单个流量源的简单模拟。但是,我们训练训练测试组件里远不止这些参数,包括动态的链路而不是纯粹静态的链路,而且是在模拟环境中训练而不仅仅是仿真环境。特别地,我们使用标准的网络研究工具 Mininet(Fontes et al., 2015) 和 Pantheon 平台(Yan et al.,2018)进行各种各样的网络场景的测试,测试模型的性能表现和鲁棒性,并且和最新的拥塞控制协议比较。
鲁棒性
图 6 展示了当链路带宽,时延,排队长度和随机丢包率的变化远远超过我们的训练条件时,我们的模型的表现。
万神殿 (Pantheon) 项目表明,改变这四个链路参数足以模拟各种各样的现实网络条件。(万神殿也包括第五个参数,将队列设置为固定或者指数分布的服务时间来更好的模拟行动 LTE 链路,在 mininet 平台里没有这个参数)。我们在单条链路中单独的一个发端进行 2 分钟的测试。对于每一个测试,我们把我们模型的结果和 TCP CUBIC (当前拥塞控制的标准协议)和 PCC Vivace (Dong et al. 2018, a robust, state-of-the-art algorithm)进行比较。我们的补充材料中包括了和其他最新的算法的比较。除非另有说明,Mininet 链路配置 30 Mbps 带宽,30 ms 的延迟,1000个包排队,0%的随机丢包。#带宽变化实验。我们选取 1.2 Mbps – 6 Mbps 链路带宽训练我们的模型,但是,实际中可能在更大带宽范围内发生拥塞。在图 6a 中,我们展示了 Aurora 在 1 Mbps – 128 Mbps 之间表现很好,这一带宽范围是训练范围的20倍以上,我们在我们的标准链路配置上,为每个测试配置不同的带宽,范围从1到128 Mbps。我们的模型在所有容量下都实现了近乎完美的链路利用率,延迟远低于 TCP,与 pc – vivace 相当。#延迟变化实验。我们在 50ms – 500ms 的延迟范围训练我们的 Aurora 模型,但是很多互联网络的延迟远远低于(很少更高)这个范围。为了测试我们的模型在不同延迟的链路上的鲁棒性,我们实验选择的延迟范围是1 ms – 512 ms 。Aurora在1ms延迟时表现很差,因为我们的模拟环境包括了真实的数据包处理,这个过程会在延迟上增加大约1ms的噪声,但在训练中没有出现。#链路队列变化实验。我们在链路队列大小在 2 – 2981 个包的范围训练我们的 Aurora 模型。对这组实验来说,我们改变队列大小在 1-10000 个包。图 6c 我们的模型吞吐量和PCC-Vivace 在所有的队列长度上相当,比 TCP CUBIC 吞吐量有很大的提升。#丢包率变化实验。我们在 0% – 5% 的随机丢包率变化范围内训练 Aurora 模型,这一范围几乎覆盖了大多数互联网状况的丢包范围。但是我们还是测到8% 的丢包率范围来验证我们模型的鲁棒性。在这个测试里, Aurora 在更高的丢包情况下比其他算法提供了接近容量的吞吐量。#动态的链路变化实验。一些网络链路,特别是移动的网络链路中,信道容量取决于实时的信号强度变化,是否受到干扰、距离或者环境的影响。链路容量的确切动态变化很大,因此我们测试了一个简化的情景。在这个场景中,我们考虑链路的容量每5秒在16 Mbps – 32 Mbps 之间完全随机的选择一个值。我们让 Aurora 和五个基准机制每次实验两分钟,至少在这条动态链路上进行 5 次实验。图 7 的结果如预期所料。
图 7 中这些方案在延迟和吞吐量之间有不同的权衡点,TCP CUBIC 以更高的时延为代价换来高吞吐量,而且在很多网络环境中有差的表现(见 Dong et al. 2015 and references therein)。Aurora取得接近 BBR 的吞吐量但是有更地的时延。最近的设计致力于降低延迟,以更好地支持小型web查询、实时视频和游戏等应用程序。在这些低时延的机制中, Aurora 比 PCC-Vivace 平均取得了更高的吞吐量和更低的时延,比 RemyCC (Winstein & Balakrishnan, 2013)在相近的时延下取得更高的吞吐量,使得 Aurora 更适合这些动态链路。最后,Aurora 性能接近 Copa ,4.2% 的更优吞吐量和 16% 更差的时延。
评估总结
我们的评估结果表明两个关键的结论。首先,Aurora 在其训练集范围之外鲁棒性很强。第二, Aurora 接近或者超过如今最先进的拥塞控制算法(BBR, PCC-Vivace, RemyCC, and Copa)。这表明利用深度 RL 研究拥塞控制,即使是一个相当简单的神经网络结构和相当有限的训练,可能也会比人为设计的协议取得更好的性能。
第五部分—— RL 拥塞控制的测试床
现有的网络模拟器包含了网络的复杂方面,包括可达性、路由、包头解析,以及许多其他因素,这些因素可能对其他领域有用,但与拥塞控制无关。这些额外的特色复杂化并且减慢了训练拥塞控制算法的过程。为了训练 Aurora ,我们实现了一个新的模拟器,逼真地模仿互联网链接的各种特点。这一模拟器足够精确,使得在这个模拟其中训练模型比在第 4 节中提到的模拟器表现更好。利用标准的网络工具通过虚拟的网络接口使用真实的 LINUX 堆栈发送真实的数据包。为了以最标准和最易访问的方式向机器学习社区开放我们的互联网拥塞控制环境,我们提供了一个基于我们内部模拟器的OpenAI Gym环境,其整个代码库是几百行纯 Python 代码。这一部分包含基础的设计和三个抽象模型(链路,数据包和发送端),我们使用这些抽象模型去简化模拟网络。这一环境的完整描述的源代码和说明,见我们的 github 仓库。
链路
我们模拟的链路,其中队列先进先出,有万神殿中定义的四个关键参数:带宽、时延、随机丢包率和队列长度,每一个变量都和真实计算机网络中提供同样的目的。表 1 提供了在我们例子中设置的参数的范围。
数据包
包信息包括链路信息和真正通信数据,但是我们并不关心这些数据,而且我们的链路非常简单。对我们而言,数据包只是这样一个源组<发送端,延迟,是否丢包>。sender 里告诉我们路径,latency 告诉我们当 ACK 到达的时候发端观察什么,is_droped 告诉我们是否应该返回一个 ACK 。
数据发送端
发送端就是我们网络中的智能体,包括发送速率、发送路线和一系列观察值。发送端的速率决定发端以多块的速率向路径中发送数据包,路由是数据和确认遍历的链接列表。这条路由在网络创建时是固定的,这是一个相当现实的情况,因为互联网路由的变化比拥塞控制决策的变化要慢几个数量级。发端然后然后进行观察,并将观察结果交给我们的机器学习智能体。图 8 列出了我们发送端观察元素列表,选择了包含在之前拥塞控制算法中有意义的值。
使用上图中 3 个对象在我们的环境中创造一个完整的网络是很简单的,这篇论文中使用的 gym 环境样例仅仅使用两条链路(想象街道上两个车道)和一个发送端对象。链路初始包含带宽、延迟、队列长度和丢包率的有限随机数值,如表 1 所列出来的。发送端被给定一个初始发送的速率,链路带宽 30% – 150% 之间,然后开始采取行动。
第六部分——仍然存在的挑战
我们在第 4 节的结果表明深度强化学习确实能够学习有用的拥塞控制策略,这和精心设计的拥塞控制算法匹敌。除了这些有希望的结果,我们也讨论一些我们这种 RL 模式没有解决的拥塞控制的一些方面,这可能对于后续的研究是很重要的。我们希望我们的 OpenAI Gym 环境能都鼓励更多在这一方面的研究。
公平性
在 Internet 网络上有许多不同的拥塞控制协议,我们的拥塞控制有很大的可能在一些场景中表现的不公平,我们既没有像Remy (Winstein & Balakrishnan, 2013)那样使用全局优化,也没有像(Dong et al., 2015;2018)那样使用博弈论均衡分析。但是,我们的智能体可能对于传统的 TCP 比较友好。更糟糕的是,如果它在一个与TCP竞争的环境中训练,它可能会学会偶尔造成数据包丢失,只是为了迫使TCP后退并释放网络容量。那么问题来了,我们的 RL 智能体和其他的协议(TCP, PCC, BBR, Copa)一起能够训练的更好吗?
多目标
像之前提到的一样,拥塞控制的目标是一个有争议的话题,用户可能在减小延迟、增加吞吐量和其他一些性能指标之间有不同的折中方案。多目标的 RL (Vamplew et al., 2011)是在不同的奖励因子上解决这种的框架,这个可能能在这个方面应用。但是,我们不知道最近在这个方向有任何深度 RL 研究。
网络变化的泛化和适应
我们的结果是在特定的网络条件下训练 Aurora 得到的,我们表明我们训练网络条件的选择产生的拥塞控制策略在更大的测试范围内表现很好。尽管这些实证结果很有前途,但是 RL 的泛化和迁移问题仍然是研究的活跃领域(Tamar et al., 2016; Barreto et al., 2017;Narasimhan et al., 2017; Higgins et al., 2017),能够为这些拥塞控制策略在训练范围之外性能表现提供保证是这一方法在实际中应用的有价值的研究。在网络中的变化侦察对 RL 本身也是一个有意义的挑战,这也为安全采用 RL 训练的策略提供了一个研究方向。例如,当我们侦测到网络状况和我们的训练条件变化很大,我们可以回退到一些精心设计的拥塞控制协议中去。这个问题是新颖的检测的一个实例(Schölkopf et al., 2000),并且新的使用深度网络的方法理论上可以用在这个地方(Zenati et al., 2018; Mandelbaum & Wein-shall, 2017)。
第七部分——相关工作
RL 应用于相当专门的内容。过去几篇研究将 RL 应用于特别专门的领域。研究者提出在 ATM 网络中利用 RL (Tarraf et al., 1995; Shaio et al.,2005)。这些早先的 RL 利用浅显的神经网络。另外,这些研究是专门针对 ATM 网络(一种被提出的如今使用的 Internet 协议的可选替代)定制的,例如,(Tarraf et al., 1995)需要使用ATM的多路复用器缓冲区中的单元数来测量拥塞。(Hwang et al., 2005)使用 RL 为多媒体网络改善拥塞控制。这些之前提到的深度 RL ,是在核心网络中使用协作路由器,在这之中利用率是可以直接观察到的,以达到全局平衡。相反,我们针对广泛部署的传输层拥塞控制的情况,其中发送方在有限的信息下单独行动。最近有两个研究利用了 Q-learning (Watkins & Dayan,1992)用在专门的领域:(Li et al., 2016)这一篇研究用其优化了记忆存储有限的物联网设备上的 TCP 协议。(Silva et al., 2016) 这一篇研究论文,是将 Q-learning 用在了高延迟,容忍中断的 DTN 网络上,适用于不是持续的端到端的连接,例如星际网络,这一方法并不适用于通常的互联网传输。(Ruffy, 2018)使用深度 RL 方法应用到数据中心的拥塞控制,并且在这个方面为基于RL的拥塞控制研究提供了一个OpenAI Gym 环境作为基准。不像 Internet 拥塞控制,其每个发送者都是独立工作,,数据中心是被一个单独的管理机构统一管理,(Ruffy, 2018)这篇论文利用全局网络视角优化整网范围内的奖励函数。在互联网拥塞控制中使用非深度的 RL 方法。(Kong et al., 2018)基于 TCP 框架提出一个 RL 解算器。(Kong et al., 2018)这篇论文和我们的工作不一样,它采用相当古老的 RL 算法(SARSA, (Sut-ton et al., 1998)),而不是深度 RL 方法。另外,动作空间和可能的奖励值都是相当小(尺寸为4),这很大限制了模型对模式学习和反映的能力。最后, RL 机制值和TCP 1999年的变形(namely, TCP NewReno (Floyd & Henderson, 1999))和 Q-learning 机制(Li et al., 2016)比较。基于明确的网路假设的离线的拥塞控制优化。 Remy(Winstein& Balakrishnan, 2013)是一个离线的网络拥塞的优化框架。Remy 明确的网络假设作为输入,例如链路带宽的专门假设、计算机连接的数量以及其他,也包含一个优化目标。然后, Remy 产生一个随机的网络模型,并且计算出一个代表这个模型的接近最优的拥塞控制协议。因此,与RL不同,Remy不会学习对流量和网络条件的模式做出反应,但是,依赖人工设置的假设。当流行的流量/网络条件偏离Remy的输入假设时,可能会导致较差的性能。通过在线学习的拥塞控制(multi-armed bandits,多臂强盗)。PCC (Dong et al., 2015; 2018)利用在线学习技术指导拥塞控制。虽然这提供了有价值的最坏情况保证(即,不后悔),但与Aurora不同的是,它不学习普遍的网络规律和相应的调整速率。因此,虽然PCC确实提供了鲁棒性,但它不能自定义到经验丰富的网络条件,并且我们的评估显示了我们的方法提供更高性能的场景。
第八部分——结论和下一步工作
我们提出了Aurora,一个由深度RL驱动的拥塞控制协议。我们的评估结果表明,即使只有相当有限的训练,Aurora也具有最先进的竞争力。我们强调了应解决的关键挑战,以简化此类方案在现实世界的采用。在未来的工作中,我们计划扩展我们的模拟软件,以包括真实的辅助数据,并支持多智能体决策。为了促进对深度rl引导的拥塞控制的进一步研究,我们开放了我们的代码和基于OpenAI Gym接口的测试套件。
版权声明:本文内容转自互联网,本文观点仅代表作者本人。本站仅提供信息存储空间服务,所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至1393616908@qq.com 举报,一经查实,本站将立刻删除。