Abstract	拥塞控制技术的笔记一
Authors	Walter Fan
Category	learning notes
Status	WIP
Updated	2022-2-10

引言

如果带宽足够的话, 没有拥塞,没有大的延迟和抖动, 那么语音和视频的发送和接收都会很顺滑,一切会很美好.

现实总是很残酷的, 网络会断, 会丢包, 会变慢，在路由节点上会排队，会拥塞，就象城市的环线道路，平常车来车往，道路通畅，一到上下班的时候，大大小小的车辆就象乌龟一样慢慢向前爬。

视频会议需要低延迟和高带宽，可是实际情况中，高带宽是难以保证的，一旦网络出现拥塞，原本就不宽阔的“马路” 堵得更窄，延迟更大。这时候，就需要做拥塞控制

在网络会议中，如果延迟太大，对在线交流就会产生影响。语音会感觉很明显，视频相对迟钝一些。

以视频来说，据研究，大致的关系如下

延迟	感觉
0 ~ 400 毫秒	在交流过程中感觉不到延迟
400 ~ 800 毫秒	能感觉到延迟，但不影响沟通和交流
800 毫秒及以上	能感觉到延迟，并且影响沟通和交流

以一个每秒 24 帧 640*480 分辨率，以 H.264 编码的视频流，视频的比特率和用户感觉的关系如下

比特率	感觉
> 800kbps	用户对视频的清晰度感到满意，感知不到视频图像信息的丢失
480 ~ 800kbps	用户对视频的清晰度基本满意，有些人能感知到视频图像信息的丢失
< 480kbps	用户对视频的清晰度很不满意，大多数时候难以分辨出图像的细节

已有三种主要的拥塞避免算法提出来，详见下表

Feature	GCC	NADA	SCReAM
Metrics	One-way delay variation,loss ratio	One-way delay, loss ratio	One-way delay, loss ratio
Architecture	Sender-side or hybrid	Sender-side	Sender-side
Actuation mechanism	Rate-based	Rate-based	Window-based
Network support	None	ECN, PCN	ECN
Implementation status	Chrome/Edge, Firefox, Safari	Ns-2 and Ns-3 simulators	OpenWebRTC and simulator

1. GCC by Google

Google Congestion Control (GCC) 被应用于 Chrome 浏览器，是相对比较成熟的算法.

2. NADA by Cisco

Network Assisted Dynamic Adaptation(NADA) 由思科提出，还未应用于实际产品中，有相关的模拟器实现

3. SCReAM by Ericsson

Self-Clocked Rate Adaptation for Multimedia(SCReAM) 由爱立信提出，应用于 OpenWebRTC，有相关的模拟器实现

算法设计

目标

拥塞控制算法的目标是产生尽可能接近可用的端到端带宽的发送速率，同时保持队列占用尽可能低。

此外，WebRTC 应用程序生成的媒体流应该与其他并发流公平地共享网络带宽。

基本要求：在最多几百毫秒之内，接收方能够连贯流畅地听到或看到发送方的声音，图像或视频。

具体要求, 参见 RFC8836

拥塞控制算法必须尝试为交互式实时流量提供尽可能低的延迟传输，同时仍然提供有用的带宽量。
该算法必须对其他流公平，包括实时流（例如自身的其他实例）和 TCP 流，包括长期存在的流和突发流量，例如典型的 Web 浏览会话生成的流量。
该算法不应该由于竞争带宽而使得 TCP 流饥饿，并且应该尽可能避免 TCP 流饥饿
该算法应该尽快适应流开始时的初始网络条件。
如果 RTP 流停止或不连续时（例如，当使用 VAD 语音活动检测时），算法应该是稳定的。
在可能的情况下，当 RTP 流共享一个公用的瓶颈时，算法应该综合考虑在两个端点之间发送的多个 RTP 流之间的信息，无论这些流是否复用相同的端口。
该算法不应该需要来自网络元素的任何特殊支持才能传达与拥塞相关的信息。
由于这里假设是一组 RTP 流，反向通道通常应该通过 RTP 控制协议 (RTCP) 完成
由该算法管理的流和在瓶颈处相互竞争的流可能具有不同的差分服务代码点 (DSCP) 2 [RFC5865] 标记，具体取决于流量类型，或者可能受基于流的 QoS 的约束。
该算法应该将反向信道(backchannel)信息的意外缺失, 感知为信道过度使用问题的可能指示，并相应地做出反应, 以避免导致拥塞崩溃的突发事件。
当应用主动队列管理 (AQM: Active Queue Management) 算法时，该算法应该是稳定的并保持低延迟。另请注意，这些算法可能适用于瓶颈中的多个队列或单个队列。

简而言之，针对以下几个主要的指标，有如下需求

指标	需求
延迟 Latency	尽可能低于 100ms
丢包 Packet losses	越少越好，可应用 FEC
吞吐量 Throughput	越高越好
突发性 Burstiness	要产生一个平滑的发送速率
公平性 Fairness	应在实时媒体流和数据流之间公平地分享带宽
饥饿 Starvation	媒体流不应由于过度竞争而使 TCP 流饥饿
网络支持 Network support	无需特别的网络支持即可运行

选择

满足这些要求的算法设计面临着几个选择

The transport protocol 传输协议
Congestion detection 拥塞检测
The actuation mechanism to be employed 所采用的驱动机制

通过端到端的度量来检测拥塞的方法可以分为两大类：

基于丢包的算法 Loss-based algorithms
基于延迟的算法 Delay-based algorithms

拥塞检测可以是隐式的（基于在端点执行的端到端测量），也可以是显式的（通过监视路由器的缓冲区长度，在网络元素中直接测量拥塞）。

一般来说，基于延迟的算法优于基于损失的算法，有如下两个原因：

首先，基于延迟的方案可以在数据包因缓冲区溢出而丢失之前检测到拥塞；
其次，基于损失的算法无法控制排队延迟，因为它们通过填充和耗尽 Internet 缓冲区不断探测网络可用带宽，从而产生显着的延迟变化。

注意：

显式控制排队延迟也是必要的，因为过大的缓冲区可能会导致几秒的延迟
需要考虑的一个重要问题是在尽力而为的互联网中与基于损失的流量竞争时，防止基于延迟的流量被饿死。
拥塞控制算法可以使用从网络元素发送到端点的显式拥塞信号来补充端到端测量，例如通过使用显式拥塞通知 (ECN) 机制。

关于驱动机制, 拥塞控制算法或者计算一个 congestion window (window-based approach) ，或者显式计算一个 sending rate (rate-based approach).

基于速率的机制的使用使得可以直接使用拥塞控制算法计算的速率来驱动媒体编码器，而在基于窗口的算法的情况下，应该执行从窗口到速率的适当转换。

度量指标

Packet Loss 丢包
RTT 往返时间
Jitter 抖动
Delay
4.1 One Way delay
4.2 One-Way Delay Variation (OWDV)

前 3 个指标不用说了，RTP 协议中有详细说明，通过 RTCP 也能够计算出来，参见以前写的笔记实时传输协议RTP 和RTCP

One way delay (OWD)单向延迟很简单，表示接收时间减去发送时间，如图所示，

而One-Way Delay Variation(OWDV) 单向延迟变化，表示发送间隔与到达时间之间的差

OWDV 的值有三种情况:

1. OWDV > 0: 排队延迟在增长
1. OWDV < 0: 排队延迟在减小
1. OWDV = 0: 排队延迟保持在一个恒定的值:
- 3.1 拥塞队列是空的：发送速率小于传输能力，不需要排队
- 3.2 拥塞队列是满的：发送速率大于传输能力，排队堵住了
- 3.3 拥塞队列是空的：发送速率等于传输能力，排队有序通过

第 3 种情况下，队列保持不变，OWDV 介于零和其最大值之间。这是一种称为站立队列的不良情况，它会不断延迟传入流量。因此，为了在充分利用可用带宽的同时保证较小的队列占用，算法必须通过增加其发送速率来持续探测可用带宽，直到检测到正排队延迟变化。此时，发送速率应迅速降低。总而言之，需要引入一些排队延迟来运行基于延迟变化的拥塞控制算法

GCC

WebRTC 中应用较广的是 Google 提出来的 GCC(Google Congestion Control), 它有两个版本

GCC v1: 通过 RTP abs_send_time header 和 RTCP REMB message 扩展，基于丢包和延迟估算带宽占用和是否有拥塞，从而调整媒体流的发送速率，主要的估算和决策在接收方，采用了卡尔曼滤波
GCC v2: 通过 RTP transport wide cc sn header 和 RTCP transport feedback message 扩展，基于丢包和延迟估算带宽占用和是否有拥塞，从而调整媒体流的发送速率，主要的估算和决策在发送方，采用了线性回归和最小二乘法

后面有时间来详细讲讲 GCC v2 的设计和实现

参考资料

Analysis and Design of the Google Congestion Control for WebRTC
What is RMCAT congestion control, and how will it affect WebRTC?
RMCAT work group
RMCAT documents: RTP Media Congestion Avoidance Techniques documents
RFC8825: Overview: Real-Time Protocols for Browser-Based Applications
RFC8836: Congestion Control Requirements for Interactive Real-Time Media
RFC8083: Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions
RFC8698 Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media
RFC8888 RTP Control Protocol (RTCP) Feedback for Congestion Control
RFC3168 The Addition of Explicit Congestion Notification (ECN) to IP

拥塞控制技术笔记之理论篇

引言

相关文档

相关术语

技术实践

算法设计

目标

选择

度量指标

GCC

参考资料

你可能感兴趣的:(拥塞控制技术笔记之理论篇)