WebRTC congestion control v1
Table of Contents
title WebRTC congestion control v1
participant WebrtcSender as sender
participant SendSideCongestionController as controller
participant TransportFeedbackAdpater as adapter
participant AcknowledgedBitrateEstimator as ack_estimator
participant ProbeController as probe_controller
participant DelayBasedBwe as delay_based_bwe
participant BitrateController as bitrate_controller
->sender: RecvPacket
alt RTCP of transport feedback
sender->controller: OnTransportFeedback(feedback)
controller->adapter: onTransportFeedback(feedback)
end
alt currently_in_alr
controller->ack_estimator: SetAlrEndedTimeMs(now_ms)
controller->probe_controller: SetAlrEndedTimeMs(now_ms)
end
controller->ack_estimator: IncomingPacketFeedbackVector(feedback_vector)
controller->ack_estimator: bitrate_bps()
controller->delay_based_bwe:IncomingPacketFeedbackVector(...)
delay_based_bwe-->controller: result
alt result.updated
controller->bitrate_controller: OnDelayBasedBweResult(result)
controller->controller: MaybeTriggerOnNetworkChanged()
end
alt result.recovered_from_overuse
controller->probe_controller: RequestProbe()
end
alt in_cwnd_experiment
controller->controller: LimitOutstandingBytes(adapter.GetOutstandingBytes())
end| Class | Responsibility | Collaborators | Comments |
| TrendlineEstimator | Estimate bandwidth usage as trendline | TrendlineEstimatorSettings | implement interface DelayIncreaseDetectorInterface |
| DelayBasedBwe | Estimate bandwidth based on delay | ||
| AimdRateControl | A rate control implementation based on additive increases of bitrate when no over-use is detected and multiplicative decreases when over-uses are detected. | When we think the available bandwidth has changes or is unknown, we will switch to a "slow-start mode" where we increase multiplicatively. | |
| SendSideBandwidthEstimation | LossBasedBandwidthEstimation LossBasedBweV2 | UpdateReceiverEstimate |
Comments |1|
Category: Uncategorized
* Measure the inter-packet timing of incoming RTP packets, and compare with expected arrival times (typically using RTP timestamps).
* If packets are arriving consistently late, tell the sender to reduce bitrate The amount of reduction is typically not dramatic, but may be proportional to the arrival slowdown
* If it appears that packets are arriving faster than expected, a queue is draining, so maintain bitrate.
* If packets are arriving on-time, allow the sender to increase bitrate (how fast is one of many ad-hoc proprietary details to these schemes