拥塞控制技术的笔记一: 理论篇

Posted on Thu 10 February 2022 in Journal

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 用户对视频的清晰度很不满意,大多数时候难以分辨出图像的细节

相关文档

标准化组织有两个工作组在从事拥塞控制相关的研究和标准制订

一个是 rmcat 工作组,全称是 RTP Media Congestion Avoidance Techniques 实时通信媒体拥塞避免技术工作组

一个是 acvcore 工作组,全称是 Audio/Video Transport Core Maintenance (avtcore) 音视频传输核心维护工作组

rmcat 工作组专注于拥塞避免技术,发布了若干了拥塞避免技术和测试方法相关的文档

  • draft-ietf-rmcat-rtp-cc-feedback-08 Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences

  • RFC 8298 (was draft-ietf-rmcat-scream-cc) Self-Clocked Rate Adaptation for Multimedia

  • RFC 8382 (was draft-ietf-rmcat-sbd) Shared Bottleneck Detection for Coupled Congestion Control for RTP Media

  • RFC 8593 (was draft-ietf-rmcat-video-traffic-model) Video Traffic Models for RTP Congestion Control Evaluations

  • RFC 8698 (was draft-ietf-rmcat-nada) Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media

  • RFC 8699 (was draft-ietf-rmcat-coupled-cc) Coupled Congestion Control for RTP Media

  • RFC 8836 (was draft-ietf-rmcat-cc-requirements) Congestion Control Requirements for Interactive Real-Time Media

  • RFC 8867 (was draft-ietf-rmcat-eval-test) Test Cases for Evaluating Congestion Control for Interactive Real-Time Media

  • RFC 8868 (was draft-ietf-rmcat-eval-criteria) Evaluating Congestion Control for Interactive Real-Time Media

  • RFC 8869 (was draft-ietf-rmcat-wireless-tests) Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks

acvcore 工作组专注于音视频的传输,也发布了几个拥塞控制相关的文档

  • RFC 6679 (was draft-ietf-avtcore-ecn-for-rtp) Explicit Congestion Notification (ECN) for RTP over UDP

  • RFC 8083 (was draft-ietf-avtcore-rtp-circuit-breakers) Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions

  • RFC 8888 (was draft-ietf-avtcore-cc-feedback-message) RTP Control Protocol (RTCP) Feedback for Congestion Control

还有另外一些文档也提及了拥塞控制相关的技术

  • rfc2914 Congestion Control Principles
  • rfc8085 UDP Usage Guidelines
  • rfc8834 Media Transport and Use of RTP in WebRTC
  • rfc5348 TCP Friendly Rate Control (TFRC): Protocol Specification

相关术语

  • RMCAT: RTP Media Congestion Avoidance Techniques 即 RTP 媒体拥塞避免技术

  • Queuing Delay 排队延迟

  • Delay gradient 延迟梯度

  • Kalman filter 卡尔曼滤波

  • inter-depature delta time 发送间隔时差

  • inter-arrival delta time 接收间隔时差

  • inter-group delay variation 包间延迟变化

  • GCC: Google Congestion control 谷歌拥塞控制

  • BBR: Bottleneck Bandwidth and Round-trip propagation time 瓶颈带宽和往返传播时间

  • PCC: Performance-oriented Congestion Control 基于性能的拥塞控制

  • TCC: Transport-wide Congestion Control 传输带宽控制

  • REMB: Receiver Estimated Maximum Bitrate 接收端估计最大比特率

  • ECN: Explicit Congestion Notification (ECN) 显式的拥塞通知

  • Starvation: 饥饿,如果某个传输通道由于其他传输通道抢占了带宽而没有得到流量,称为饥饿

  • TMMBR: Temporary Maximum Media Stream Bit Rate Request 临时最大媒体流带宽请求

  • TMMBN: Temporary Maximum Media Stream Bit Rate Notification 临时最大媒体流带宽通知, 表示 TMMBR 收到

  • QP: Quantization Parameter, that ranges from 0 to 51. 量化参数 QP 越小,细节保留得越多,质量就更好, 反之质量越差,压缩率更高

技术实践

工业界的技术实践常常领先标准文档一步,实践形成理论,理论指导实践,实践再反过来影响和验证理论,从来都是这样一个螺旋上升的循环。

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

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

  1. 拥塞控制算法必须尝试为交互式实时流量提供尽可能低的延迟传输,同时仍然提供有用的带宽量。

  2. 该算法必须对其他流公平,包括实时流(例如自身的其他实例)和 TCP 流,包括长期存在的流和突发流量,例如典型的 Web 浏览会话生成的流量。

  3. 该算法不应该由于竞争带宽而使得 TCP 流饥饿,并且应该尽可能避免 TCP 流饥饿

  4. 该算法应该尽快适应流开始时的初始网络条件。

  5. 如果 RTP 流停止或不连续时(例如,当使用 VAD 语音活动检测时),算法应该是稳定的。

  6. 在可能的情况下,当 RTP 流共享一个公用的瓶颈时,算法应该综合考虑在两个端点之间发送的多个 RTP 流之间的信息,无论这些流是否复用相同的端口。

  7. 该算法不应该需要来自网络元素的任何特殊支持才能传达与拥塞相关的信息。

  8. 由于这里假设是一组 RTP 流,反向通道通常应该通过 RTP 控制协议 (RTCP) 完成

  9. 由该算法管理的流和在瓶颈处相互竞争的流可能具有不同的差分服务代码点 (DSCP) 2 [RFC5865] 标记,具体取决于流量类型,或者可能受基于流的 QoS 的约束。

  10. 该算法应该将反向信道(backchannel)信息的意外缺失, 感知为信道过度使用问题的可能指示,并相应地做出反应, 以避免导致拥塞崩溃的突发事件。

  11. 当应用主动队列管理 (AQM: Active Queue Management) 算法时,该算法应该是稳定的并保持低延迟。另请注意,这些算法可能适用于瓶颈中的多个队列或单个队列。

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

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

选择

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

  1. The transport protocol 传输协议

  2. Congestion detection 拥塞检测

  3. The actuation mechanism to be employed 所采用的驱动机制

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

  1. 基于丢包的算法 Loss-based algorithms

  2. 基于延迟的算法 Delay-based algorithms

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

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

  • 首先,基于延迟的方案可以在数据包因缓冲区溢出而丢失之前检测到拥塞;

  • 其次,基于损失的算法无法控制排队延迟,因为它们通过填充和耗尽 Internet 缓冲区不断探测网络可用带宽,从而产生显着的延迟变化。

注意:

  • 显式控制排队延迟也是必要的,因为过大的缓冲区可能会导致几秒的延迟

  • 需要考虑的一个重要问题是在尽力而为的互联网中与基于损失的流量竞争时,防止基于延迟的流量被饿死。

  • 拥塞控制算法可以使用从网络元素发送到端点的显式拥塞信号来补充端到端测量,例如通过使用显式拥塞通知 (ECN) 机制。

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

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

度量指标

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

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

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

$$OWD = t_i - T_i$$

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

$$OWDV = t_i - t_{i-1} - (T_i - T_{i-1})$$

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), 它有两个版本 1. GCC v1: 通过 RTP abs_send_time header 和 RTCP REMB message 扩展,基于丢包和延迟估算带宽占用和是否有拥塞,从而调整媒体流的发送速率,主要的估算和决策在接收方,采用了卡尔曼滤波

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

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

参考资料