自学内容网 自学内容网

深入浅出WebRTC—ALR

ALR(Application Limited Region)指的是网络传输过程中,由于应用层的限制(而非网络拥塞)导致带宽未被充分利用的情况。在这种情况下,应用层可能因为处理能力、手动配置或其他因素无法充分利用可用带宽,导致实际传输速率低于网络最大可能提供的速率。因此,在进行拥塞控制或带宽估算时,识别和处理 ALR 状态对于避免不必要的码率下调或误判网络状况至关重要。

1. 配置

ALR逻辑比较简单,配置项就3个,主要用来协助定义进入和退出ALR状态的规则。

struct AlrDetectorConfig {
  // ALR使用的带宽是估计带宽乘以一个比例系数
  double bandwidth_usage_ratio = 0.65;
  // 带宽使用从高点下降,且剩余可用带宽占总容量的比例达到或超过此值时,视为开始进入ALR状态。
  double start_budget_level_ratio = 0.80;
  // 当带宽使用回升,且实际使用比例再次超过此值时,认为已从ALR状态中恢复出来。
  double stop_budget_level_ratio = 0.50;
  std::unique_ptr<StructParametersParser> Parser();
};

2. 静态结构

ALR实现只有两个类,AlrDetector提供接口,其内部使用IntervalBudget来更新ALR状态,对外接口只有三个:

1)OnBytesSent:每发送完一个报文需要调用此接口,此接口完成Budget水位的更新。

2)SetEstimatedBitrate:设置估计带宽,估计带宽会影响Budget水位调整的细节。

3)GetApplicationLimitedRegionStartTime:如果有值,表示进入ALR状态,否则表示退出ALR状态。这里为什么不用一个bool值来表示是否处于ALR状态,是因为某些逻辑需要知道是什么时候进入ALR状态和什么时候退出ALR状态的。

3. 调用流程

ALR处理逻辑主要涉及两个调用链,一个是发送报文后,调用AlrDetector::OnBytesSent更新Budget水位,通过Budget水位才能判断当前ALR状态;另一个是带宽评估变化调用AlrDetector::SetEstimatedBitrate设置估计带宽,估计带宽会影响水位更新细节和ALR状态判断规则。

4. 实现

4.1. Bucket模型

为了便于理解WebRTC是如何判断ALR状态,引入一个Bucket模型。Bucket中的水位表示当前Budget,可以认为是账户余额,IncreateBudget会向账户中存入资金,增加账户余额,从而提高Bucket中的水位;UseBudget会从账户中支取资金,减少账户余额,从而降低Bucket中的水位。

IntervalBudget是Bucket模型的实现者,只是Budget从金钱换成了数据,每过一段时间 t 计算应该发送的数据:估计带宽 * t,这些数据会存入Budget,每次发送完报文,需要消耗报文对应数据量的Budget。

相关逻辑代码如下:

void AlrDetector::OnBytesSent(size_t bytes_sent, int64_t send_time_ms) {
  ...

  int64_t delta_time_ms = send_time_ms - *last_send_time_ms_;
  last_send_time_ms_ = send_time_ms;
  // 减少Budget
  alr_budget_.UseBudget(bytes_sent);
  // 增加Budget
  alr_budget_.IncreaseBudget(delta_time_ms);

  ...
}

通过定义桶的高度,并在桶上面画上80%和50%两个刻度,bytes_remaining_为当前Budget水位,从而形成了一个完整的Bucket模型,如下图所示,图中变量与代码中变量一一对应。

其中桶高度max_bytes_in_budget_定义如下:

void IntervalBudget::set_target_rate_kbps(int target_rate_kbps) {
  // 更新目标速率
  target_rate_kbps_ = target_rate_kbps;

  // 计算时间窗口内最多可以发送多少数据,kWindowMs = 500
  max_bytes_in_budget_ = (kWindowMs * target_rate_kbps_) / 8;

  ...
}

4.2. 估计带宽

从上面的Bucket模型可知,估计带宽会影响到桶的高度和Budget流入的速度。外部会向AlrDectector实时更新估计带宽,但AlrDetector不会全部使用,而是乘以一个系数0.65(这看起来像是一个经验值)再设置到IntervalBudget。

void AlrDetector::SetEstimatedBitrate(int bitrate_bps) {
  RTC_DCHECK(bitrate_bps);
  int target_rate_kbps =
      static_cast<double>(bitrate_bps) * conf_.bandwidth_usage_ratio / 1000;
  alr_budget_.set_target_rate_kbps(target_rate_kbps);
}

4.3. 水位变化

Bucket中的水位用bytes_remaining_表示,80%和50%两条水位线将桶的水位位置划分为三个区:A、B、C,则水位的变化可以穷举为:A -> B、A -> C、B -> A、B -> C、C -> A、C -> B六种情况。

WebRTC实现定义如果水位处于A区,则一定是“进入ALR”状态,因为实际发送数据远少于应该发送数据;如果水位处于C区,则一定是“退出ALR”状态,因为实际发送数据已经大于应该发送数据。B区是一个过渡区,它的ALR状态和上一个水位相关,下面我们看下水位在A、B和C三个区中动态变化中,ALR状态的变化。

4.3.1. A -> B

刚开始处于“进入ALR”状态,bytes_remaining_比例从高于80%,下降到低于80%但高于50%,ALR状态保持不变。

4.3.2. A -> C

刚开始处于“进入ALR”状态,bytes_remaining_比例从高于80%,下降到低于50%,变为“退出ALR”状态。

4.3.3. B -> A

刚开始可能处于“进入ALR”状态也可能处于“退出ALR”状态,bytes_remaining_从低于80%但高于50%变为高于80%。

1)如果刚开始处于“进入ALR”状态(从A区进入B区),则状态保持不变,仍为“进入ALR”状态;

2)如果刚开始处于“退出ALR”状态(从C区进入B区),则变为“进入ALR”状态。

总之,不管之前是什么状态,进入A区后肯定是“进入ALR”状态。

4.3.4. B -> C

刚开始可能处于“进入ALR”状态也可能处于“退出ALR”状态,bytes_remaining_从低于80%但高于50%变为低于50%。

1)如果刚开始处于“进入ALR”状态(从A区进入B区),则状态变为“退出ALR”状态;

2)如果刚开始处于“退出ALR”状态(从C区进入B区),则状态保持不变,仍为“退出ALR”状态。

总之,不管之前是什么状态,进入C区后肯定是“退出ALR”状态。

4.3.5. C -> A

刚开始处于“退出ALR”状态,bytes_remaining_从低于50%变为高于80%,变为“进入ALR”状态。

4.3.6. C -> B

刚开始处于“退出ALR”状态,bytes_remaining_从低于50%变为高于50%但低于80%,状态保持不变。

4.4. 状态机

以上ALR状态跟随水位变化可以用状态机表示如下:

对应源码为:

void AlrDetector::OnBytesSent(size_t bytes_sent, int64_t send_time_ms) {
  ...

  if (alr_budget_.budget_ratio() > conf_.start_budget_level_ratio && !alr_started_time_ms_) {
    // 进入ALR
    alr_started_time_ms_.emplace(rtc::TimeMillis());
    state_changed = true;
  } else if (alr_budget_.budget_ratio() < conf_.stop_budget_level_ratio &&
    alr_started_time_ms_) {
    // 退出ALR
    state_changed = true;
    alr_started_time_ms_.reset();
  }

  ...
}

5. ALR应用

5.1. ProbeController

进入ALR状态后,真实发送的码率可能会远低于链路真实容量,如果长时间处于ALR状态而不进行带宽探测,持续的ACK反馈码率会影响最终估计码率,从而导致无法估计带宽失真。因此,专门设置了一个ALR带宽探测机制,进入ALR状态后,ProbeController会立即启动一个ALR带宽探测。

1)GoogCcNetworkController在OnProcessInterval中更新ALR开始时间

NetworkControlUpdate GoogCcNetworkController::OnProcessInterval(ProcessInterval msg) {
  ...

  // 获取ALR状态
  absl::optional<int64_t> start_time_ms =
      alr_detector_->GetApplicationLimitedRegionStartTime();

  // 设置ALR状态
  probe_controller_->SetAlrStartTimeMs(start_time_ms);

  ...
}

2)在OnTransportPacketsFeedback中更新ALR结束时间

NetworkControlUpdate GoogCcNetworkController::OnTransportPacketsFeedback(
    TransportPacketsFeedback report) {
  ...

  // 获取ALR状态
  absl::optional<int64_t> alr_start_time =
      alr_detector_->GetApplicationLimitedRegionStartTime();

  // 退出ALR状态
  if (previously_in_alr_ && !alr_start_time.has_value()) {
    int64_t now_ms = report.feedback_time.ms();
    acknowledged_bitrate_estimator_->SetAlrEndedTime(report.feedback_time);
    probe_controller_->SetAlrEndedTimeMs(now_ms);
  }
  
  ...
}

3)ProbeController会定时检测ALR状态,适时启动ALR带宽探测,探测码率是当前评估码率的2倍,带宽探测结果在带宽探测机制中获得。

std::vector<ProbeClusterConfig> ProbeController::Process(Timestamp at_time) {
  ...

  // 以两倍估算带宽进行探测:alr_probe_scale("alr_scale", 2)
  if (TimeForAlrProbe(at_time) || TimeForNetworkStateProbe(at_time)) {
    return InitiateProbing(
        at_time, {estimated_bitrate_ * config_.alr_probe_scale}, true);
  }

  ...
}

5.2. AcknowledgedBitrateEstimator

ACK码率估计器使用贝叶斯估计算法,其中很重要的一个参数就是数据样本的不确定性,应用如果进入ALR状态,则说明此时真实发送的码率低于链路容量,当前ACK样本不能真实反映链路带宽,则应该适当增加当前数据样本的不确定性,使得带宽评估值更加真实可靠。

1)GoogCcNetworkController在OnSentPacket中设置ALR状态

NetworkControlUpdate GoogCcNetworkController::OnSentPacket(SentPacket sent_packet) {
  alr_detector_->OnBytesSent(sent_packet.size.bytes(), sent_packet.send_time.ms());
  acknowledged_bitrate_estimator_->SetAlr(
      alr_detector_->GetApplicationLimitedRegionStartTime().has_value());
  ...
}

2)在OnTransportPacketsFeedback中更新ALR结束时间

NetworkControlUpdate GoogCcNetworkController::OnTransportPacketsFeedback(
    TransportPacketsFeedback report) {
  ...

  // 获取ALR状态
  absl::optional<int64_t> alr_start_time =
      alr_detector_->GetApplicationLimitedRegionStartTime();

  // 退出ALR状态
  if (previously_in_alr_ && !alr_start_time.has_value()) {
    int64_t now_ms = report.feedback_time.ms();
    acknowledged_bitrate_estimator_->SetAlrEndedTime(report.feedback_time);
    probe_controller_->SetAlrEndedTimeMs(now_ms);
  }

  ...
}

3)ALR刚结束,码率增速会比正常快,增加贝叶斯估计器历史数据的方差,也就是历史数据的贡献变小,能够更快速响应码率变化。

void AcknowledgedBitrateEstimator::IncomingPacketFeedbackVector(
    const std::vector<PacketResult>& packet_feedback_vector) {
  ...

  for (const auto& packet : packet_feedback_vector) {
    // ALR刚结束,设置码率估计器快速响应新的码率
    if (alr_ended_time_ && packet.sent_packet.send_time > *alr_ended_time_) {
      bitrate_estimator_->ExpectFastRateChange();
      alr_ended_time_.reset();
    }
    ...
  }
}

4)贝叶斯估计器在更新数据时,如果当前正处于ALR状态,会为数据样本赋予一个更大的不确定性,使得其在整体数据中的贡献占比降低。

void BitrateEstimator::Update(Timestamp at_time, DataSize amount, bool in_alr) {
  ...

  float scale = uncertainty_scale_;
  if (is_small_sample && bitrate_sample_kbps < bitrate_estimate_kbps_) {
    scale = small_sample_uncertainty_scale_;
  } else if (in_alr && bitrate_sample_kbps < bitrate_estimate_kbps_) {
    // Optionally use higher uncertainty for samples obtained during ALR.
    scale = uncertainty_scale_in_alr_;
  }

  ...
}

5.3. DelayBasedBWE

由于在 ALR 状态下获取的反馈不是链路满载下的反馈,基于这种反馈向上调整带宽估计值很可能是不准确的,因此,ALR 状态保持原来的估计值,是比较明智的。

void AimdRateControl::ChangeBitrate(const RateControlInput& input, Timestamp at_time) {
  absl::optional<DataRate> new_bitrate;
  ...
  switch (rate_control_state_) {
    case RateControlState::kRcHold:
      break;
    case RateControlState::kRcIncrease: {
      // ALR状态不允许升速
      if (send_side_ && in_alr_ && no_bitrate_increase_in_alr_) {
        increase_limit = current_bitrate_;
      }
    ...
  }
  ...
}

5.4. LossBasedBweV2

基于丢包的带宽估计器,在全局搜索最优带宽和固有丢包率组合时,需要先构造候选带宽。如果当前正处于 ALR 状态,ACK 码率不能反映网络真实带宽,不应该将 ACK 码率作为候选带宽(可配置)。

std::vector<LossBasedBweV2::ChannelParameters> LossBasedBweV2::GetCandidates(bool in_alr) const {
  ...
  // 添加一个基于 ACK 码率但进行了回退因子调整的候选带宽
  if (acknowledged_bitrate_.has_value() &&
      config_->append_acknowledged_rate_candidate) {
    if (!(config_->not_use_acked_rate_in_alr && in_alr) ||
        (config_->padding_duration > TimeDelta::Zero() &&
         last_padding_info_.padding_timestamp + config_->padding_duration >=
             last_send_time_most_recent_observation_)) {
      bandwidths.push_back(*acknowledged_bitrate_ *
                           config_->bandwidth_backoff_lower_bound_factor);
    }
  }
  ...
}

6. 总结

识别 ALR 状态对 WebRTC 的拥塞控制来说非常重要,很多人可能没有意识到这一点。为什么这么说,是因为,WebRTC 的拥塞控制算法本质上是一种“刀尖上跳舞”的算法,只有当你要求的最大带宽超过链路容量时,才需要做拥塞控制,此时 WebRTC 会在链路容量的上限疯狂试探。如果带宽随便你使用,怎么用都用不完,怎么用都不会造成拥塞,那也就没必要做拥塞控制了。

ALR 状态本质上是用来标识当前带宽是否够用,进入 ALR 状态和退出 ALR 状态,所需要的控制策略是不一样的,相关算法都需要做调整。ALR 状态就像一个全局开关,开和关直接控制着拥塞控制的行为。


原文地址:https://blog.csdn.net/zhh157/article/details/140560446

免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!