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

虽然视频会议已商用了多年,特别是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. 为什么Xmind输入小写的英文自动变成大写了

  2. js & click copy to clipboard

    js & click copy to clipboard https://www.cnblogs.com/xgqfrms/p/9999061.html https://www.cnblogs. ...

  3. Windows系统下搭建Appium自动化测试框架

    简介 一种开源的测试框架(http://appium.io/) 能够用来测试原生Android/iOS应用.混合应用以及webapp 通过webdriver协议来操作应用,其核心是一个web服务器,接 ...

  4. Python之路3【第零篇】目录

    Web应用框架篇 1.Web应用框架前戏

  5. BZOJ3156 防御准备(动态规划+斜率优化)

    设f[i]为在i放置守卫塔时1~i的最小花费.那么显然f[i]=min(f[j]+(i-j)*(i-j-1)/2)+a[i]. 显然这是个斜率优化入门题.将不与i.j同时相关的提出,得f[i]=min ...

  6. 【CF938G】Shortest Path Queries(线段树分治,并查集,线性基)

    [CF938G]Shortest Path Queries(线段树分治,并查集,线性基) 题面 CF 洛谷 题解 吼题啊. 对于每个边,我们用一个\(map\)维护它出现的时间, 发现询问单点,边的出 ...

  7. BZOJ2288:[POJ Challenge]生日礼物——题解

    https://www.lydsy.com/JudgeOnline/problem.php?id=2288 ftiasch 18岁生日的时候,lqp18_31给她看了一个神奇的序列 A1, A2, . ...

  8. 梯度下降法求解函数极大值-Matlab

    目录 目录题目作答1. 建立函数文件ceshi.m2. 这是调用的命令,也可以写在.m文件里3. 输出结果题外话 题目 作答 本文使用MATLAB作答 1. 建立函数文件ceshi.m functio ...

  9. OpenJudge1001Exponentiation

    问题描述 Problems involving the computation of exact values of very large magnitude and precision are co ...

  10. tp 事务处理

    tp的事务开启是非常简单的, 只需要M()->startTrans();//开启事务,M()可以是M('xxx') $m->rollback();//事务回滚 $m->commit( ...