随着网络带宽的日益增加和便携式设备,如智能手机或平板电脑处理能力的增强,基于互联网的实时通信已经成为热点。

虽然视频会议已商用了多年,特别是SKYPE这样的视频应用在互联网上已有10年时间,但针对实时音视流高效传输的内部控制标准却是空白。所以标准化组织IETF和W3C准备解决这个问题(2011-2013年)。

IETF的RTCWeb 想法是把用于实时媒体流的网络拥塞控制算法标准化成协议。 W3C的WebRTC想法是标准化一套HTML5的API用于网络浏览器的实时流媒体。

CISCO向IETF提出NADA(Network Assisted Dynamic Adaptation)算法,但目前还没给出实现。

Ericsson也向IETF提出SCReAM(Self-Clocked Rate Adaptation for Multimedia)。Scream的目标网络偏向无线网LTE 3G 4G。

Google向IETF提出的是GCC(Google Congestion Contrl)。

本次要介绍的是Google Congestion Contrl。

1. GCC是什么?

GCC是Google Congestion Contrl的缩写,用于实时媒体通讯的网络拥塞控制算法。不是C/C++的编译工具^_^。

GCC基于UDP,它已实现于开源软件WebRTC项目,也集成到M23后的chrome版本,同时应用在Google Hangouts应用中。

实时媒体通讯的网络拥塞控制有三个难点

l 媒体信源不能立刻按要求调整成指定的带宽,通常媒体信源的变化是不连续甚至是跳变的,变化的幅度也大。

l 即使网络拥塞已经被发现,参与的两端也不确定要如何反应,减少带宽不一定是正确的做法。

l 越是压缩率高的编码器越对网络丢包敏感,但网络实时性的要求基本要排除丢包重传的使用。

业界对媒体流的网络拥塞算法已有标准并开放,主要方法是基于速率的控制,通过平滑窗口的算法实现平滑的数据发送,如TFRC(TCP Friendly Rate Control)和RAP(Rate Adaptive Protocol)。

TCP偏向使用基于丢包率来感知网络拥塞,当网络设备因为拥堵引入队列时,没有丢包但要求实时性的双向媒体传输是不能接受的。 另一种是基于时延的方法感知网络拥塞,业界对哪种方案更优一直在争议。

GCC使用两种拥塞控制的算法来应对共享带宽网络的拥塞控制。

2. 基于时延的网络拥塞控制

GCC里基于时延的网络拥塞控制由三部分组成。

l 到达时间滤波器arrival-time filter

l 过载检查器over-use detector

l 速率控制器rate controller

GCC中使用包间间隔时间为度量,可以是两个网络包间也可以是两组包间的间隔。

d(i) = t(i) - t(i-1) - (T(i) - T(i-1))

d(i)表示时延,t(i) - t(i-1)是到达时间,T(i) - T(i-1)是发送时间。

一列数据包短时间里连续发送,这段时间称为突发时间,建议突发时间为5ms。不建议在突发时间内的包间隔时间做度量,而是把它们做为一组来测量。这种组包发送的形式在WI-FI和无线网络里常常这么用。

T(i)用到达包里的时间戳,或一组到达网络包最后一包的时间戳。如到达包有乱序则不采用其数据。

当我们把定义发送时间一组长度为L的数据包通过能力为C的通道。

ts = L/C于是我们建模有

d(i) = dL(i)/C(i) + w(i)

=  dL(i)/C(i) + m(i) + v(i)

w(i)是随机函数W的信号量,它的输入因子有吞吐能力C(i),当前网络阻塞情况,当前速率。在这种模型中我们认为输吞吐能力C比其它参数相对稳定,接近常数或变化缓慢。

我们再把w(i)建模成白色高斯过程,于是当对信道过载使用时,w(i)会增加,当信道通过数据量减少时,w(i)会减少,其他情况w(i)为0。

从这个模型我们可知,传输的数据量越大所要的时间越长需要相对时延也更大。而网络抖动和其他影响时延的因素不被采集和考虑。

因为d(i)和dL(i)是简单可测量的,那么通过w(i)预测C(i)可用一个自适应滤波器来实现,如使用卡尔曼滤波器Kalman filter。

3. 卡尔曼滤波

数据滤波是去除噪声还原真实数据的一种数据处理技术,

卡尔曼Kalman滤波在测量方差已知的情况下能够从一系列存在测量噪声的数据中,估计动态系统的状态,由于它便于计算机编程实现, 并能够对现场采集的数据进行实时的更新和处理, Kalman滤波是目前应用最为广泛的滤波方法.

卡尔曼滤波是一种利用线性系统状态方程,通过系统输入输出观测数据,对系统状态进行最优估计的算法。由于观测数据中包括系统中的噪声和干扰的影响,所以最优估计也可看作是滤波过程。

卡尔曼滤波不要求信号和噪声都是平稳过程的假设条件。对于每个时刻的系统扰动和观测误差(即噪声),只要对它们的统计性质作某些适当的假定,通过对含有噪声的观测信号进行处理,就能在平均的意义上,求得误差为最小的真实信号的估计值。

假设状态空间的n-1时刻估计值和观测空间的n时刻测量值都满足独立高斯分布,Kalman滤波器就是通过高斯分布的乘积运算将估计值和测量值结合,获得最接近真值的n时刻估计。高斯分布乘积运算的结果仍为高斯分布,高斯分布的均值对应n时刻的估计值,高斯分布的方差对应n时刻的均方误差。

4. 过载探测器

d(i) =  dL(i)/C(i) + m(i) + v(i)

m(i)是从滤波器获取到的预测值,当预测值高于阀值gamma_1(i)则过载探测器发出过载信号给速率控制器。附加条件有这个过载状态需要持续gamma_2毫秒时间。如果m(i)小于m(i-1),即使高于阀值也不需要发出过载信号。相对应的负数区间也是如此,如m(i)小于-gamma_1(i)时,过载被发现。

所以阀值gamma_1对算法的影响很大。如果是gamma_1是静态值会导致一系列问题,所以gamma_1需要动态调整来达到良好的表现。公式如下

gamma_1(i) = gamma_1(i-1) + (t(i)-t(i-1)) * K(i) * (|m(i)|-gamma_1(i-1))

当m(i)超过[-gamma_1(i-1),gamma_1(i-1)]时增加gamma_1(i),而当m(i)落入[-gamma_1(i-1),gamma_1(i-1)]区间时减少gamma_1(i)。当|m(i)| - gamma_1(i) > 15,建议gamma_1(i)不更新。K(i)为更新系数。

同时建议gamma_1(i)控制在[6,600]区间。太小的值会导致探测器过于敏感。建议增加系数要大于减少系数K_u > K_d。

其实建议值如下

gamma_1(0) = 12.5 ms

gamma_2 = 10 ms

K_u = 0.01

K_d =  0.00018

5. 速率控制器

速率控制器由两个控制器组成,一个是基于时延的预测控制,另一个是基于丢包的的预测控制。控制器内部置状态机,结合过载探测器进行状态的切换。

6. 基于丢包的控制

前面介绍基于时延的控制是有一个假设前提,即传输通道的缓冲足够大。当传输通道的缓冲很小时,通过时延是观测不到过载状态的,这时需要丢包率来表示过载。

l 当接收侧感知到2-10%丢包率,发送端的预测值不变。

l 当实际丢包率超过预测值10%时,新的预测值可更新为As_hat(i) = As_hat(i-1)(1-0.5p),其中p为丢包率。

l 当实际丢包率小于2%时预测时可更新为As_hat(i) = 1.05(As_hat(i-1)),其中p为丢包率。

在GCC中基于丢包的预测值不应大于基于时延的预测,也不应小于基于TFRC(rfc3448)的预测。

7. 参考

https://tools.ietf.org/html/draft-ietf-rmcat-gcc-00#page-10

https://tools.ietf.org/html/rfc3448

Google Congestion Control介绍的更多相关文章

  1. TCP Congestion Control

    TCP Congestion Control Congestion occurs when total arrival rate from all packet flows exceeds R ove ...

  2. (转)Google Fonts 的介绍与使用

    转载自“前端笔记”  http://www.cnblogs.com/milly/archive/2013/05/10/google-fonts.html Google Fonts 是什么?(以下翻译为 ...

  3. Google Optimization Tools介绍

    Google Optimization Tools(OR-Tools)是一款专门快速而便携地解决组合优化问题的套件.它包含了: 约束编程求解器. 简单而统一的接口,用于多种线性规划和混合整数规划求解, ...

  4. Google Protocol Buffers介绍

    简要介绍和总结protobuf的一些关键点,从我之前做的ppt里摘录而成,希望能节省protobuf初学者的入门时间.这是一个简单的Demo. Protobuf 简介 Protobuf全称Google ...

  5. 【神经网络与深度学习】Google Protocol Buffer介绍

    简介 什么是 Google Protocol Buffer? 假如您在网上搜索,应该会得到类似这样的文字介绍: Google Protocol Buffer( 简称 Protobuf) 是 Googl ...

  6. Google Breakpad · 基础介绍

    Google breakpad是一个跨平台的崩溃转储和分析框架和工具集合. 三个主要组件 ◆ client 以library的形式内置在你的应用中,当崩溃发生时写 minidump文件 ◆ symbo ...

  7. Network | TCP congestion control

    拥塞控制算法:1. 加性增.乘性减:2. 慢启动:3. 对超时事件作出反应: 整体过程如下: 慢启动->到达阈值->加性增(窗口+1个MSS), 这个阶段叫拥塞避免(CA)->3个冗 ...

  8. 实时视频应用之QoS关键技术分析

    转自:http://www.aiweibang.com/m/detail/104476372.html?from=p 随着WebRTC标准的逐步推广,实时音视频通讯技术受到越来越多公司和技术人员的关注 ...

  9. WebRTC的拥塞控制技术<转>

    转载地址:http://www.jianshu.com/p/9061b6d0a901 1. 概述 对于共享网络资源的各类应用来说,拥塞控制技术的使用有利于提高带宽利用率,同时也使得终端用户在使用网络时 ...

随机推荐

  1. [转帖]nvidia nvlink互联与nvswitch介绍

    nvidia nvlink互联与nvswitch介绍 https://www.chiphell.com/thread-1851449-1-1.html 差不多在一个月前在年度gtc会议上,老黄公开了d ...

  2. Java代码中谁拿到了锁?

    我们都知道当一个线程试图访问同步代码块时,它首先必须得到锁,退出或抛出异常时必须释放锁.这些基础也许大家都知道,但是很多人还是搞不清哪个对象才是锁?如果你能正确回答以下问题,那么才算你彻底搞明白了哪个 ...

  3. BZOJ5294 BJOI2018二进制(线段树)

    二进制数能被3整除相当于奇数.偶数位上1的个数模3同余.那么如果有偶数个1,一定存在重排方案使其合法:否则则要求至少有两个0且至少有3个1,这样可以给奇数位单独安排3个1. 考虑线段树维护区间内的一堆 ...

  4. MT【123】利用第一次的技巧

    已知 \(r_1=0,r_{100}=0.85,(r_k\) 表示投 k 次投中的概率.) 求证:(1)是否存在\(n_0\)使得\(r_{n_0}=0.5\) (2)是否存在\(n_1\)使得\(r ...

  5. 洛谷 P2184 贪婪大陆 解题报告

    P2184 贪婪大陆 题目背景 面对蚂蚁们的疯狂进攻,小\(FF\)的\(Tower\) \(defence\)宣告失败--人类被蚂蚁们逼到了\(Greed\) \(Island\)上的一个海湾.现在 ...

  6. 【bzoj4542】 Hnoi2016—大数

    http://www.lydsy.com/JudgeOnline/problem.php?id=4542 (题目链接) 题意 给出一个素数$P$,一个数串$S$,$m$个询问,每次询问区间$[l,r] ...

  7. java Class.getSimpleName() 的用法

    Usage in android: private static final String TAG = DemoApplication.class.getSimpleName(); public cl ...

  8. Webpack 学习笔记总结

    Webpack安装 Linux系统默认已经安装了node&npm,但版本比较低,而且没法升级,可以重新下载Node然后通过软链接替换系统自带的node和npm; ln -s /path_to/ ...

  9. 【cdq分治】【P4390】[BOI2007]Mokia 摩基亚

    Description 给你一个 \(W~\times~W\) 的矩阵,每个点有权值,每次进行单点修改或者求某子矩阵内权值和,允许离线 Input 第一行是两个数字 \(0\) 和矩阵大小 \(W\) ...

  10. python调用powershell、远程执行bat

    python调用本地powershell方法 1.现在准备一个简陋的powershell脚本,功能是测试一个IP列表哪些可以ping通: function test_ping($iplist) { f ...