深入浅出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)!