Advanced Computer Network Review(4)——Congestion Control of MPTCP
这篇文章对有关MPTCP的拥塞控制进行理解和梳理，参考资料来自：
《Design, implementation and evaluation of congestion control for multipath TCP》(NSDI’11)和老师上课时的PPT。
复习提纲中要理解的问题是：
1.MPTCP拥塞控制的目标
2.理解EWTCP和Coupled
3.可以判断EWTCP和Coupled各自获取的带宽
一、MPTCP拥塞控制的目标
这部分是自己的理解和总结，从论文中来看，MPTCP拥塞控制的目标有两个：
1.确保MPTCP的引入不会对原有网络流量造成严重干扰(公平性等)
2.尽可能地保证高吞吐率
正如论文原文说的那样：
The basic question we set out to answer is how precisely to adapt the subflow windows of a multipath TCP so as to get the maximum performance possible, subject to the constraint of co-existing gracefully with existing TCP traffic.
“我们打算作出回答的一个基本问题是：如何精确地调整MPTCP的子流窗口，以便在与现有TCP流量和谐共存的约束下获得最大可能的性能。(笑)”
二、理解EWTCP和Coupled
MPTCP协议本质是作为一个传输层的中间件出现的，它的主要目的是将一个数据流划分到多个路径上传输。一个TCP连接管理多个subflow，每个subflow可以在网络中进行自由选路，并且每一个subflow都维护着属于自己的一个私有的发送窗口WrW_rWr，而MPTCP的发送者则在任何一个subflow发送窗口有余量时将数据分发给它们去传输，以上是对MPTCP的一个简要概括。
首先从最开始的故事说起，原始TCP(Regular TCP)中的拥塞控制算法如下。
这个和经典的TCP拥塞控制是一致的，就像上一篇BBR中提到的一样，它有一些特性：比如AIMD(加性增，乘性减)，吞吐率波动大，算法侵略性强等。
如果直接将原始的TCP拥塞控制用在MPTCP场景中，那么MPTCP的每一个subflow都将以独立的竞争者身份和原始的单路径TCP流进行竞争，这样显然对单路径TCP是非常不利的。可以想象，假设在RTT相同的情况下，一个拥有n个subflow的MPTCP，其最终获取的带宽将会是单路径TCP的n倍，极大地损害了网络的公平性，不能实现与现有TCP流量的和谐共存。
那么首先要解决的问题就是公平性，一个非常朴素的思想就是给每个流可以获得的带宽进行一个加权限制，进而引出了EWTCP(Equally-Weighted TCP)拥塞控制算法：
关于这个算法有一个重要的结论：每一个subflow会获得的发送窗口值正比于a2a^2a2，此结论的证明需参考另一篇论文，此处从略。
那么可以想见的是，如果取a=1na = \frac{1}{\sqrt{n}}a=n1，并且假设RTT值都相等，就会使得最终含有n个subflow的MPTCP作为一个整体可以在瓶颈链路上获得和一个单路径TCP同样的网络带宽，从而强行地获得了分配上的公平性。(一个MPTCP实体在EWTCP协议下，无论它下辖多少subflow，它所能获得的总带宽总不会超过一个单路径TCP实体)
当n = 1时，EWTCP会退化到Regular TCP拥塞控制算法。此外，EWTCP算法中涉及到的MPTCP每一个subflow彼此之间相互独立(因为是按照WrW_rWr来进行拥塞控制的)，所以即使有一条subflow被阻塞了，其他的subflow也不会因此变得更加有侵略性，这保证了MPTCP实体不可能在总占用带宽上超过单路径TCP。
EWTCP实现了带宽竞争中的公平性，但是论文中同样指出EWTCP不能高效地使用链路(缺乏动态适应性，就像上面说的，一个subflow如果阻塞了，也不会影响到其他subflow，但是MPTCP获得的总带宽却实打实减少了)。论文中举出的一个典型的例子如下：
三个n=2的MPTCP使用EWTCP去竞争三条带宽为12Mb/s的链路，使用EWTCP的结果是三者各自在两条信道上分4Mb/s的带宽。每一个MPTCP实体获得的带宽总额是8Mb/s，但其实最优解可以是每个MPTCP获得12Mb/s的带宽，即一个MPTCP只走一条链路，这样就可以不走程序直接赢麻(写累了，笑)，但是EWTCP不能自己找到这样的最优解，而是呆呆地执行“看似公平”的次优解。
文中指出，已有理论上的证据表明：对于多路径传输的情形，最优解总是将其所有流量迁移至拥塞程度最低的路径。而且有一种算法在理论上被证实，不需要进行拥塞程度侦测也可以自适应地找到最优解，这就是COUPLED算法：
其中WtotalW_{total}Wtotal是一个MPTCP实体下管辖的所有subflow的发送窗口大小之和。要理解这个协议需要分两种情况：
2.1 各个链路拥塞程度相等的情况
这种情况下不存在选路的自适应问题，也就是说每个subflow都可以大致地按照一个确定的发送窗口大小去运作，但是有一个要尊重的基本法(笑)，那就是：每一个subflow的发送窗口增长和发送窗口减少，从长远来看一定要相互抵消，就是解下面这个方程(p是丢包率，1-p是成功发送概率)：
解出来发现Wtotal=2(1−p)(p)≈2pW_{total} = \sqrt{2(1-p)(p)} \approx \sqrt{\frac{2}{p}}Wtotal=2(1−p)(p)≈p2，这直接指向了另外一个重要结论：在COUPLED算法中，一个MPTCP的各个subflow可以获得的总带宽之和只与链路丢包率有关，这证明了COUPLED拥有天然的带宽竞争公平性，这是各个链路丢包率相同时的情况。
2.2 各个链路拥塞程度不同的情况
首先注意COUPLED算法中对每一条subflow而言，每次增加或减少的窗口值对所有subflow是统一的，只与那个时刻的WtotalW_{total}Wtotal有关。那么拥塞程度高的链路势必在指定的一段时间内会遇到更多的丢包，长远来看最终算法会慢慢地将其流量逐渐向低拥塞链路汇集，从而实现了EWTCP没有实现自适应功能。
更加有趣的是，文中提到一个结论：将流量从高拥塞链路向低拥塞链路迁移的动作会带来全网络的丢包率逐渐收敛到均衡。这意味着如果执行COUPLED算法，2.2状态会最终向2.1状态过渡(惊喜)，最终达到收敛时各个MPTCP实体都会获得相等的全局链路带宽，这直接引出了下一部分的问题：如何计算？
三、判断EWTCP和Coupled各自获取的带宽
其实文章写到这里，这个问题已经比较显而易见了，举个论文中的例子：
3.1 EWTCP的计算
对于EWTCP，它会倾向于友好地和每一个竞争者保持均等分配。所以在上面左图中，12Mb/s的链路和10Mb/s的链路都会被均分。所以：
- A会获得的带宽：5+6 = 11
- B会获得的带宽：6+5 = 11
- C会获得的带宽：5+3 = 8
3.2 COUPLED的计算
首先根据我们上面的解释，各个MPTCP实体会获得相等的全局链路带宽，所以它们最终会获得的带宽是一致的，设为统一的x。设以下未知量：
写个方程组解它就是了…
Advanced Computer Network Review(4)——Congestion Control of MPTCP相关推荐
- Advanced Computer Network Review(5)——COPE
本文参考资料来自: 1.论文原文<XORs in The Air: Practical Wireless Network Coding>(SIGCOMM'06) 2.课程演示文稿 根据复习 ...
- A Google Congestion Control Algorithm for Real-Time Communication
原文地址 https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc Abstract 摘要 This document describes ...
- 一周一论文（翻译）——[SIGMOD 2015] TIMELY RTT-based Congestion Control for the Datacenter
本文主要解决的问题是在,基于优先级的拥塞控制PFC是一种粗粒度的机制,它主要是通过检测优先级队列的长度是否超过阈值,然后再发送PFC拥塞信号帧来进行流量控制.这种做法会带来不公平性以及行头阻塞等问题. ...
- Computer Network Homework3’ s hard question
Computer Network Homework3' s hard question 1. Which kind of protocol does CSMA belong to? A. Random ...
- TCP Congestion Control
TCP Congestion Control Congestion occurs when total arrival rate from all packet flows exceeds R ove ...
- 数据报拥塞控制协议：DCCP（Datagram Congestion Control Protocol）
目录 Datagram Congestion Control Protocol ethereal/wireshark support GStreamer support TODO & test ...
- 计算机网络环境及应用系统的安装与调试（Computer network environment and application system installation and debugging）
计算机网络环境及应用系统的安装与调试(Computer network environment and application system installation and debugging) W ...
- [Codeforces 555E]Case of Computer Network(Tarjan求边-双连通分量+树上差分)
[Codeforces 555E]Case of Computer Network(Tarjan求边-双连通分量+树上差分) 题面 给出一个无向图,以及q条有向路径.问是否存在一种给边定向的方案,使得 ...
- Elasticity Detection:A Building Block for Internet Congestion Control读后感
这周我读的论文是Elasticity Detection:A Building Block for Internet Congestion Control.这篇论文提出了一个新的度量"弹性& ...
- WebRTC的拥塞控制技术（Congestion Control
http://www.jianshu.com/p/9061b6d0a901 1. 概述 对于共享网络资源的各类应用来说,拥塞控制技术的使用有利于提高带宽利用率,同时也使得终端用户在使用网络时能够获得更 ...
最新文章
- 互联网高并发架构技术实践
- 在ASP.Net中两种利用CSS实现多界面的方法（转）
- 用VB.NET(Visual Basic 2010)封装EXCEL VBA为DLL_COM组件(二)
- 用技术谱写美好生活，「亚马逊云科技线上黑客松2021」报名开启！
- java二维码生成-谷歌（Google.zxing）开源二维码生成学习及实例
- 读书记录（持续更新...）
- SQLyog学习笔记04---数据库表操作CRUD基本指令
- VB.net 播放 WAV音乐
- oracle siebel crm 8.0,Solix实现Oracle Siebel CRM 8.1整合
- 编辑中的word变成只读_word只读模式怎么改 word保存文件提示此文件为只读无法保存修改方法...
- 基于Linux的socket网络编程项目——游侠手机商城
- 实验一 网络流量捕获实验
- vcruntime140d.dll丢失的解决方法_vcruntime140d.dll修复工具下载
- 工作十年之感悟 -- 兼谈生活与人生
- css border实现图形
- 华三交换机irf堆叠以及BFD检测配置
- 【数据恢复】【傲梅分区助手】
- Mac电脑下载的google chrome无法使用
- html5游戏制作入门系列教程（一）
- linux vfe框架,bsp内核的摄像头使用