注意:本文仅代表个人对该篇论文的理解,如果对您有帮助那是我的荣幸,如有不当之处欢迎留言讨论,如需转发请注明出处链接
原文在这里,是MIT AI Lab在13年中的一篇SIGCOMM。
Remy 与 RemyCC
首先,这篇论文所探究的问题最近也正困扰着我:TCP拥塞控制本身是一个动态的过程,每一步的选择都可能造成后面所有反馈的不同,如何能判定一个拥塞控制是“表现得最好”的?
于是这篇论文的解决办法是:既然人看不出好不好,那就用机器预先算出给定网络里每个决策可能造成的所有后果,选最终评分最高的,把它一路过来的所有决策用来生成一个CC,那肯定就是“表现得最好的”。
因此,Winstein和Balakrishnan设计了Remy算法来算出不同参数的拥塞控制策略产生的结果,细化较优结果的参数进行优化,经过几轮迭代后,用生成最优结果的所有决策生成最优CC,就是RemyCC。
Remy的输入
Fig.1 展示了Remy的大致流程,其中第一个输入是网络的先验假设,也就是把网络参数化。作者用ns-2进行网络环境的模拟,具体设置的参数包括:
· 瓶颈链路的速度: bitrate / bandwidth
· 网络路径传输延迟:rtt / queueing delay
· 多路复用的程度: number of senders
第二个输入是发送端的流量发送模型。Remy建模时把流量变化过程看作很多对独立的sender-receiver链路随机开/关的过程,每条链路开的持续时间遵循特定的分布。
第三个输入是目标方程。用于计算给某链路分配资源的得分。其中x代表链路比特率,alpha和beta代表throughput和delay的权衡,权重表示对其赋予的重要性。
Remy寻找最佳拥塞控制策略的过程
一些概念
Remy把在特定网络环境下寻找最佳RemyCC的过程看作为一个Dec-POMDP搜索最佳策略的过程。对于端到端的拥塞控制来说,每一个时间点,agent根据接收的observation,做出调整拥塞窗口的action。
作者把sender端的observation用三个参数来表示,统称memory:
· ack_ewma:ack的到达间隔的指数加权移动平均值
· send_ewma:ack的发送间隔的指数加权移动平均值
· rtt_ratio:最新RTT除以最小RTT
把sender端的action(控制拥塞窗口大小)也用三个参数来表示:
· m >= 0:cwnd的乘系数
· b:cwnd的加系数(可为负数)
· r > 0:连续发送的最小间隔时间,单位mm
把一条memory映射到一条action的过程称为一条rule。一个完整的拥塞控制策略由很多条rule构成,即一张rule table。Remy的自动搜索过程就是用贪心算法建立和优化这张rule table的过程。
Remy的自动设计过程
初始action: m=1, b=1, r=0.01。所有的memory都指向该action,作为rule table的所有初始rule。
rule table的优化过程:
1.设置所有rule的epoch为current epoch
2.用current rule table构建一个CC,放入建模的网络中运行,找到current epoch下使用次数最多的rule(这一步主要是找到放入的网络trace中出现频率最高的memory);都没用,转4
3.针对2找到的rule搜索最佳action:计算最接近原本action的约100种action(e.g. 对r来说,r+-0.01, r+-0.08, r+-0.64...),抽取16种网络的traces,把调整后的action应用到所有的sender,再仿真。若某种调整后的action表现出优化,替换原本的action并重复搜索过程,使用相同的random seed;若没有action表现出优化(说明对这条memory已经找到了最优的action),这条rule的epoch++,转回2
4.如果遍历完current epoch下所有的rule,current epoch++。若新的current epoch是K的倍数,转5;否则转1。(K代表迭代的轮数,用于控制算法优化的时间)
5.recall:每条rule代表的是从一个三维长方体的memory空间到一个action的一个映射。这一步里,找到表中最多使用的rule,以及触发这条rule的memory中间值(每一维一个),产生八个新的memory(每一维一个,就想象成包裹着中间值点的一个正方体的八个顶点)赋予和中间值同样的action,然后转1.
整个算法流程至此结束。算法理解起来需要一定的时间,但如果动手跟着步骤画一下rule table的建立和优化过程,就能形象的理解了。
Remy算法的一些问题
首先,同论文里作者也发现的一样,用Remy搜索找到的最佳RemyCC,当把它用于和生成RemyCC时使用的网络相似的网络上时,效果当然非常不错,但一旦用于不同类型网络时,效果就不太如意了。这里当然是因为RemyCC只能预测它所见过的网络的最优决策,一旦遇到没见过的网络,RemyCC仍使用本身的预见方法来应对,这显然是不够灵活的。
其次,是个人的一个发现。算法的第二步里,找current epoch里使用次数最多的rule这一步,比较冗余,而且增加算法时间复杂度。原因是,既然你要遍历整个rule table,何须找使用次数最多的?直接从头开始不会比较快吗?因此个人认为不需要找使用最多的rule这一步骤。