WEBRTC浅析（九）带宽估计算法之BBR

置顶 已于 2022-05-06 22:58:50 修改
阅读量2.8k 收藏 6
点赞数
文章标签： webrtc
于 2022-05-06 22:30:40 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/muwesky/article/details/124620319
版权

带宽估计算法之BBR

此次，主要介绍一种效率更快的带宽探测策略。BBR主要的应用是在QUIC 协议里有支持。在webrtc里，也有一段时间是放到了正式版本中。此次，我就基于WEBRTC上的BBR版本和标准的bbr协议，来给大家做个大致的讲解。

BBR带宽估计 （Bottleneck Bandwidth and Round-trip propagation time）

参考文档：https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control
参考文档：https://www.ietf.org/proceedings/98/slides/slides-98-iccrg-an-update-on-bbr-congestion-control-00.pdf

一：BBR 的设计概述

  1. 网络路径模型

    • BBR 是一种基于模型的拥塞控制算法：BBR 的模型包括两个显式估计参数
      • BBR.BtlBw : bottleneck bandwidth（瓶颈带宽），根据最大发送数据率 获得
      • BBR.RTprop ：双向往返传播延迟，根据一个窗口内发送数据的最小RTT获得

  2. 目标工作点

    • BBR 使用其模型寻找具有高吞吐量的操作点和低延迟。为了在最佳工作点附近工作(具有最大吞吐量和最小延迟的点)系统需要保持两个条件：

      1. Rate balance: 最大发送速率

      2. Full pipe:

         BDP = BBR.BtlBw * BBR.RTprop

  3. 控制参数

    • BBR 使用其模型来控制其发送行为，使保持在目标工作点附近。

        1. pacing rate：BBR发送数据的速率
  2. send quantum：发送数据量
  3. cwnd：允许在飞行中的最大数据量。

  4. 状态机设计概述

    • BBR 希望通过一个简单的状态机改变其三个控制参数。

       通过状态机，从而实现高吞吐量、低延迟的目标。
 首先探测 BBR.BtlBw 然后探测 BBR.RTprop，通过顺序交替近似公平地共享带宽。


  BBR 从 Startup 状态开始，并提高其发送速率
 迅速地。当它估计管道已满时，它进入 Drain
 状态以排空队列。在稳定状态下，BBR 仅使用
 ProbeBW 状态 和（如果需要）ProbeRTT 状态

  ProbeBW 状态：定期在飞行中短暂升高以探测更高的 BBR.BtlBw 样本
  ProbeRTT 状态： 在飞行中短暂降低以探测较低的 BBR.RTprop 样本

4.1 状态转换图

下面的状态转移图总结了控制流程

            |
            V
   +---> Startup  ----+
   |        |         |
   |        V         |
   |      Drain   ----+
   |        |         |
   |        V         |
   +---> ProbeBW -----+
   |      ^    |      |
   |      |    |      |
   |      +----+      |
   |                  |
   +---- ProbeRTT <---+
  1. 算法组织

二：通过代码来了解

RTT, LOSE RATE的统计：：bandwidth_sampler.cc

  • 计算实时发送码率

      DataSize sent_delta = sent_packet.total_data_sent -
                        sent_packet.total_data_sent_at_last_acked_packet;
  TimeDelta time_delta =
      sent_packet.sent_time - *sent_packet.last_acked_packet_sent_time;
  send_rate = sent_delta / time_delta;

  • 计算实时反馈码率

      DataSize ack_delta = total_data_acked_ - sent_packet.total_data_acked_at_the_last_acked_packet;
  TimeDelta time_delta = ack_time - *sent_packet.last_acked_packet_ack_time;
  DataRate ack_rate = ack_delta / time_delta;

  • 计算实时bandwidth

        BandwidthSample sample;
    sample.bandwidth = std::min(send_rate, ack_rate);
    max_bandwidth_.Update(sample.bandwidth, round_trip_count_);

  • 计算实时rtt：：

        sample.rtt = ack_time - sent_packet.sent_time;

BBR的主要参数计算::bbr_network_controller.cc

带宽上探的过程

  1. 首先进入start up 快速上探模式
    * mode = start up
    * pacing gain = 2.885
    * 连续3个RTT target_rate > 最大带宽，判断达到 最大带宽，is_at_full_bandwidth_= true。

  2. 然后进入 drain 模式，进行排空数据
    * mode = drain
    * pacing gain = 0.34662
    * 当管道中的数据，小于一个1bdp时，认为排空结束。进入probe rtt 模式。
    * msg.data_in_flight <= GetTargetCongestionWindow

  3. 开始进入PROBE_BW模式，探测 带宽
    * EnterProbeBandwidthMode ：进入 probe bw 模式
    * 通过UpdateGainCyclePhase来计算pacing gain。

  4. 稳定后的模式：
    * pacer gain: 在1.25 ,1 , 0.75 中切换.
    * 1.25 为探测带宽是否可以上溢。
    * 0.75 为排空过程。
    * 1 为带宽维持稳定的过程。

需要了解的参数：

  • 计算实时loss rate：：

    • 这个是链路的真实丢包率，可以传到上层，给fec模块用来判断冗余的比例。

          if(packets_sent > 0){
     current_feedback_loss_rate_ = (float)((float)packets_lost/(float)packets_sent * 100);
    loss_rate_.UpdateWithLossStatus(msg.feedback_time.ms(), packets_sent, packets_lost);

  • 计算pacing_gain::

       if (round_offset == 0)
      return 1 + config_.probe_bw_pacing_gain_offset;// 1.25
    else if (round_offset == 1)
      return 1 - config_.probe_bw_pacing_gain_offset;// 0.75
    else
      return 1;

  • 计算当前bandwidth：

    • 这当网络没有丢包：bandwidth就是实际带宽。

    • 在有丢包率的情况：当前总带宽=bandwidth/(1-loss rate).

        实际透过率：这是服务器收到的feekback的数据，表示当前的可用带宽。
  bandwidth  = max_bandwidth_.GetBest()

  • 计算pacing rate：：

      	DataRate pacing_rate_ = pacing_gain_ * max_bandwidth_.GetBest();

  • 计算cwd

       	DataSize bdp = GetMinRtt() * max_bandwidth_.GetBest();
    	DataSize congestion_window = gain * bdp;

三：与Paced Sender 的互动

  1. Paced_sender 是一个数据平滑发送器，他的主要作用有两个：
    * 在带宽允许的状态下，尽快的发送带宽。
    * 如果有突发的数据，则要按间隔，分多次的发送，避免造成网络拥塞。
    * Pacer 的发送模式：Pacer 内部有一个线程，定期（默认是5ms）的执行发送rtp 包的任务。

  2. Pacer 中使用的参数

    • 设置pacing和padding的 bitrate

        * setPacingRates(uint32_t pacing_rate_bps, uint32_t padding_rate_bps
  * pacing_rate_bps 是最大的可发送码率，标明媒体数据可以发送的最大带宽。
  * padding_rate_bps 是发送padding的最大码率，一般大于 等于pacing_rate_bps，当需要探测更高的带宽时，这时 媒体信源的码率不能提升，所以只能通过发送空的padding包来填充管道，来探测是否能够达到更高的带宽。

    • 设置pacer 增益

        * pacing_gain_ = pacing_gain;
  * 在带宽稳定的的情况下gain的值为1 。只有系统希望多发一些带宽，去探测一下当前是否有更多的带宽可以用时，会希望超发一些带宽，这个时候，Pacing gain 会 > 1.
  * 当然，当系统超发后造成的管道拥塞，就会把gain 小于1，此时会开始排空管道，减少拥塞。

    • 设置拥塞窗口

        * data_in_fly(管道中的数据) = data_by_send - data_by_ack 
  * congestion_window_bytes_ = congestion_window_bytes * pacing_factor_
  * 当data_in_fly(管道中的数据) > congestion_window_bytes_ 时，表示拥塞了，Pacer 需要停下来， 等待data_in_fly 下降到小于congestion_window_bytes_时，才能重新发送数据。

  3. Pacer的优化方向：
    * 在pacer 中多加几个rtp队列，可以精准的控制媒体流的发送顺序。
    * 对nack，media，audio进行区别对待。
    * padding包的发送，可以使用媒体包来发送，从而达到加冗余的效果，提高抗弱网的性能。

muwesky
关注
webrtc bbr
debug&code的专栏
04-07 370
webrtc bbr
WebRTC发送端带宽估计(trendline)
fdsafwagdagadg6576的专栏
07-15 1282
下文前面是理论介绍,后面是源码分析 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 整体架构 上面这张图是一个比较老的架构图，但是也基本能说明整体架构，早期webrtc版本带宽估计是放到接收端处理，目前最新版本带宽估计放到了发送端，但是接收端计算得到的带宽并没有废弃，而是通过rtcp remb反馈给发送端。 在发送端带宽估计由3个元素结合决定，基于丢包率估算的带宽（丢包率通过rtcp rr得到）、接收端的remb反馈的带宽、发送端带宽估计（方法
webrtc中的带宽自适应算法
mahout_xb的专栏
01-08 8481
webrtc中的带宽自适应算法分为两种： １，　发端带宽控制，　原理是由rtcp中的丢包统计来动态的增加或减少带宽，在减少带宽时使用TFRC算法来增加平滑度。 ２，　收端带宽估算，　原理是并由收到rtp数据，估出带宽；　用卡尔曼滤波，对每一帧的发送时间和接收时间进行分析，　从而得出网络带宽利用情况，修正估出的带宽。 两种算法相辅相成，　收端将估算的带宽发送给发端，　发端结合收到的带宽
Pathchirp—有效的带宽估计方法（二）
ice110956的专栏
09-11 4261
上一个blog介绍了有效带宽估计方法：pathload。http://blog.csdn.net/ice110956/article/details/11126491。 下面介绍另一个带宽估计的算法，pathchirp。pathchirp用一个指数型递增的序列作为探测序列，使用少的多的包来进行探测，对比于pathload,在探测效率上有很大的提升。
BBR算法，自定义控制协议集成（浅谈一）
最新发布
liulilittle的博客
08-20 468
在BBR算法之中，不关心是否产生网络丢包，不关心管道的断开、打开状态等，它根据内部的状态机（四个状态）来决定，所以：对于已经到达中断报文，控制协议开发人员需要认为进行控制在中断报文以后的 cwnd 大小的控制，而不是仍旧使用BBR算法提供的 cwnd 大小，并产生更多的网络流量。BBR算法并不关心，控制协议如何处理丢包的问题，它只关心人们何时输入正确的采样样本，而样本必须在ACK的阶段之中，为它进行输入。即：BBR发送起搏速率，指示间隔多少微妙，脉冲发送 cwnd 大小限制的数据。
网络带宽预测算法（英文）
04-27
ZHANG KE XIN 网络带宽预测算法 英文版
BBR即时带宽的计算
u010643777的专栏
12-03 4483
BBR算法中每收到一个ack，就计算一下即时带宽，论文中给出的计算公式为： deliveryRate=(delivered-packet.delivered)/(now-packet.delivered_time) ,其中，假设收到的ack是对一个数据包的确认，那么delivered增加1，delivered说明的是成功接收数据包的数量，packet.delivered是数据包packet发送时
基于WebRTC的带宽估计算法实现及应用
KnBackend的博客
09-20 261
在WebRTC中，带宽估计（BWE）是一个关键组件，用于动态调整音视频传输的比特率，保证传输的稳定性和质量。本文将介绍基于WebRTC的带宽估计算法的原理以及其在实际应用中的实现。WebRTC中的带宽估计通过测量数据包的发送和接收时间间隔来估计网络的可用带宽，以实现高质量的实时音视频传输。希望读者通过本文的介绍，对WebRTC的带宽估计有更深入的了解，并能够在实际应用中灵活运用。WebRTC中的带宽估计算法基于数据包的发送和接收时间间隔来进行估计。以上是一个简单的WebRTC带宽估计的实现示例。
【WebRTC---算法原理篇】（二）BBR拥塞控制算法解析
用可见的方式来记录和分享每一次收获
11-23 1400
正文之前，给出本文的图例： BBR的组成 bbr算法实际上非常简单，在实现上它由5部分组成： 1.即时速率的计算 计算一个即时的带宽bw，该带宽是bbr一切计算的基准，bbr将会根据当前的即时带宽以及其所处的pipe状态来计算pacing rate以及cwnd(见下文)，后面我们会看到，这个即时带宽计算方法的突破式改进是bbr之所以简单且高效的根源。计算方案按照标量计算，不再关注数据的含义。在bbr运行过程中，系统会跟踪当前为止最大的即时带宽。 2.RTT的跟踪 bbr之所以可以获取非常
WebRTC系列-网络之带宽估计和码率估计(2)接收端带宽估计
HOSTEN的博客
10-20 557
上一篇介绍了WebRTC中带宽估计整体类关系；也介绍了接收端带宽估计的主要类及关系，这节就从类开始分析源码。
WebRTC系列-网络之带宽估计和码率估计(3)接收端带宽估计-发送端
HOSTEN的博客
10-24 553
在上一篇文章主要介绍了接收端带宽估计在接收端根据延迟估计评估发送端的带宽然后通过RTCP发送的过程；这一篇主要介绍WebRTC接收端带宽估计的发送端处理；
论文研究-一种基于Welch变换的信号带宽估计算法 .pdf
08-16
一种基于Welch变换的信号带宽估计算法，王佳，刘丹谱，为了提高对MPSK信号带宽盲估计的精度，本文在Welch变换的基础上，提出了一种基于Welch变换的功率谱的MPSK信号带宽的盲估计算法，并进行
BBR Congestion-Based Congestion Control
11-14
Google 高效的TCP 拥塞控制算法，基于拥塞的一种拥塞控制算法
一个linux 4.9，4.14内核的bbr带宽估计偏低问题
weixin_33912453的博客
02-21 332
linux 4.9内核，bbr的带宽估计问题。 一个正常的bbr流量图： 对应的ttl图形: 一个异常的bbr流量图： 可以看出，异常的bbr流量图，出现了一个很低的带宽，且稳定在这个带宽10s左右，而正常情况下，这个文件下载不应该超过10s，由于流量消耗大于流量的下载，导致了用户播放卡顿。 通过分析，我们确认了bbr在应对delay_ack时，出现带宽估计...
WebRTC带宽估计
fishmai的专栏
04-09 9371
带宽估计可能是WebRTC视频引擎中最重要的一部分了。带宽估计（BWE）模块的任务是决定你可以发送多大的视频流且不会造成网络拥塞，以此来保证不会降低视频质量。          在以前的带宽估计算法还是十分基础的，大体上是基于丢包而设计的。通常我们在开始慢慢的增加视频的比特率，直到我们检测到丢包为止。为了检测丢包，你使用标准的RTCP反馈，其中接收端使用RTCP接收端报告（RR）信息来周期性
网络带宽估计的方法及问题综述
ice110956的专栏
09-04 6752
现行的可用带宽估计得方法多为基于包在链路上延时的方法，由于转发链路间的带宽不同，导致包得链路延时随着链路发生变化。我们可以通过探测包对的延时时间，来估计链路的瓶颈带宽（即最小链路带宽）。
TCP BBR算法的带宽敏感性以及高丢包率下的优化
热门推荐
Netfilter
10-30 1万+
bbr算法比较简单也比较容易理解，所有关于它的优化也就同样不复杂了。        请注意，任何优化都只针对特定场景的，根本不存在一种放任四海而皆准的算法。我们分析Google的测试报告时，比较容易被忽视的是其bbr算法的部署场景。如果可以完美复现Google的B4网络，那么测试结果应该就跟Google是一致的，但不得不说，bbr算法内置了很多的参数(目前的版本中是写死的)，Google方面有没有
播放器网络带宽预测方法
wangtonghua97的博客
02-26 3680
简介 带宽预测是播放器实现码率自适应的技术基础。只有对当前的带宽预测的足够准确，才能够选择出当前场景下最优的码率进行播放。下面分别介绍下ijkplayer和exoplayer的带宽预测方法。 ijkplayer ijkplayer的带宽预测代码位于ijksdl_timer.c中，核心思想是对过去时间点的网速进行采样，使用过去所有采样点的加权均值对当前带宽进行预测。其核心结构体为SDL_SpeedSampler2： typedef struct SDL_SpeedSampler2 {
【mediasoup 带宽估计】aimd算法1 ： AimdRateControl
突围
04-13 777
E:\ADDEV\RTCTRANS\mediasoup\worker\deps\libwebrtc\libwebrtc\modules\remote_bitrate_estimator\aimd_rate_control.h rtcp_bitrate 最多为current_bitrate_的5% 计算rtcp feedback 间隔 const TimeDelta interval = kRtcpSize / rtcp_bitrate; 最小200 毫秒 最大1000 毫秒 计..
WebRTC开发详解：ICE算法与STUN检查
在WebRTC（Web Real-Time Communication）技术中，地址对的发现和验证是关键环节，尤其是对于实现点对点（P2P）通信的实时音视频传输。STUN（Simple Traversal of User Datagram Protocol Through NATs，NAT穿越简单...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值