The initial hold duration is 300ms.
Whenever it enters kDecreasing state, it will double the current hold duration. The hold duration will be reset as soon as the delay based estimate works, e.g. the state is kDelayBased to avoid getting stuck at low bitrate.
Bug: webrtc:12707
Change-Id: I3906ff80b071ba3eb6274b012fb31922f4cbc7b6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324304
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40991}
Addes field trial UpperBoundCandidateInAlr to LossBasedBweV2. If an
instant upper bound exist in ALR that are lower than current estimate,
use it as a candidate.
Bug: webrtc:12707
Change-Id: I55595c7225c4289e1bc4edde9d9576e0443d3dce
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324220
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40986}
UsePadding - signals to GoogCC that padding should be used to fill up to
BWE while BWE is ramping up.
Bug: webrtc:12707
Change-Id: I7b4922dff3a83da370c50c567050bfa748190b40
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324160
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40979}
Ensure acked bitrate is not used for lower loss based estimate if
estimate improve.
Ensure LossBasedBweV2 is in state DelayBased if reached max rate.
Bug: webrtc:12707
Change-Id: I20230b99e0c2b530570e2f2de8ea88179f795c50
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324140
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40977}
Expect OnNetworkAvailabability to be invoked when the transport becomes writable.
Before this change, ProbeController in GoogCC was expected to be created when the transport is writable or explicitly notifed after creation that network is not writable.
Bug: None
Change-Id: I623b1c34e40a82e912f85b92fea49629e7e72d4e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323463
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40975}
The state should be computed from the actual estimate rather than the best estimate candidate. The fix is NOT under field trial.
And some other cleanup:
1. Loss based result will be computed in UpdateBandwidthEstimate method. Currently it is re-computed in GetLossBasedResult.
2. Rename current_estimate to current_best_estimate to avoid misunderstanding that current_estimate is the `final estimate`. The final estimate is computed by applying lower and upper bound on current_best_estimate
3. Remove current_state_. The state is stored directly in loss_based_result_.
Bug: webrtc:12707
Change-Id: Ie612845f907b9e6333fbd8249ddc9b93ad9f8042
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324022
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40964}
This will be used in an experiment to ramp up BWE when BWE is reduced
due to loss.
Bug: webrtc:12707
Change-Id: I3b78f9dd3fe8ef9f94a9616640ffb8b2225e161e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324042
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40961}
This cl/ makes sure that the estimate cannot go lower than a factor of acked bitrate. The current flag LowerBoundByAckedRateFactor is set to 0, means we dont use it.
Bug: webrtc:12707
Change-Id: I75d5881f0b85a374af3f7039b82c71aee97fb7b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323881
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40958}
This ensure probe results can not be lower than 85% percentage of the
acked bitrate.
Bug: webrtc:11498
Change-Id: I501eeb84f7a049140c45c89e7de7e8080c13f94d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324040
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40957}
MinNumObservations is set to 3 per default as loss based BWE should not be ready if it has few feedbacks. We use a flag, rather than a const since we want to customize it for our unit tests, which often have 1-2 packet feedbacks only, and customize it later in prod if necessary.
Bug: webrtc:12707
Change-Id: Id1cd21aaf6137996de2e51cb5e33fc2a4bb07d8a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323780
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40952}
Cleanup field trials for not probing when BWE limited due to high RTT,
loss.
Bug: webrtc:14754, webrtc:12707
Change-Id: Ib664784e321d9284d842ea42a0dd1d8361000f20
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323640
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40949}
These features are not in use.
Bug: webrtc:12707
Change-Id: Ibe9fcae5e3fd7cb7ca289af80dad8480288c9ba3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323601
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40938}
A follow up cl/ is to remove passing upper link capacity from goog_cc to loss_based_bwe_v2.
Bug: webrtc:12707
Change-Id: I45af8ca6e8ba185700d0b7eb57004d2b61edeb9e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320780
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40780}
The purpose is to not allow an initial low link capacity estimate to reduce the current estimate.
Only delay overuse detection , low probe results or a loss event can
reduce the estimate.
Bug: webrtc:14392
Change-Id: Ib1618347f2c7681e3bd65d85ee687dec3cd67c97
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320380
Reviewed-by: Diep Bui <diepbp@google.com>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40751}
The sequence number is generally not used for the estimation,
but may be used as a tie-breaker when ordering packet feedbacks.
Bug: b/299667054
Change-Id: I52a5145c889c8f6924838667cc267b1cd9565f7b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320240
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40749}
Experiments has not showed significant metric changes. However, simulations has showed that RobustThroughputEstimator better follow the actually receive rate better. Especially during bursts of sent packets. Code is also simpler.
Bug: webrtc:13402 chromium:1411666
Change-Id: I38c309f74e8e1322602196354545b3a465866263
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/318040
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40653}
Start using RobustThoughputEstimator in DelayBasedBwe test in preparation for making it default.
Experiments has not showed significant metric changes. However, simulations has showed that RobustThroughputEstimator better follow the actually receive rate better. Especially during bursts of sent packets. Code is also simpler.
Bug: webrtc:13402 chromium:1411666
Change-Id: I83cfa1fc15486982b18cc22fbd0752ff59c1c1b4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/317600
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40644}
Ensure probes are not created until after the transport becomes writable even if the network route change.
DTLS negotiation must complete before there is a point in sending probes.
Bug: webrtc:14928
Change-Id: Ib3cb93aef9f38e306b094dd700ed595cf9eb3f32
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301362
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39870}
Pass FieldTrialsView by const& to note it can't be null and doesn't need to outlive the constructor
In unittests use AimdRateControl object directly instead of through helpers
Use unit types (TimeDelta, DataRate) directly, reducing their conversion to plain numbers
Replace SimulatedClock with a single Timestamp now variable or constant
Bug: None
Change-Id: I147f85e629b4d8923aa19896ea211a6f9dca1e68
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299260
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39707}
Instead of use probe_bitrate as the bandwidth estimate, the change uses probe bitrate as the bandwidth limit.
The experiment is not started, so it does not affect production.
Bug: webrtc:12707
Change-Id: Iefd8cdfe87983057489e551816bf5d4cb38f7c9f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296040
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39603}
Packet pending time should be diffed between max_revc_time and receive time as it is done at line 436. The current implementation makes pending time to be negative.
Bug: webrtc:14850
Change-Id: Ie6590ef11caa67254750591abb6bf72679d76941
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292461
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39311}
This will enable loss based bwe v2 by default. The default params were used in Chrome experiment and got positive result. Remove some tests in goog_cc, which are for loss based bwe v1.
Bug: webrtc:12707
Change-Id: Ice126a128f6e8cea8b861f879d09e390ee69e521
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/285740
Commit-Queue: Diep Bui <diepbp@google.com>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38851}
When best candidate estimate increases above the delay based estimate, the state should be DelayBasedEstimate because the final esimate is bounded by delay based bwe anyway.
Bug: webrtc:12707
Change-Id: I0bcae684b33e5f1e9a7c57cb32c431b4eb58fd35
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283802
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38677}
Add loss_limited_probe_scale as a scale factor which decides how much we should probe when bandwidth is loss limited.
Bug: webrtc:12707
Change-Id: I194b2b40c9a7861d82b61585bcaf484ab228eedb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281360
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38636}
Motivation: loss based ramp-up can be incorrect when (1) bandwidth is loss limited, and (2) delay based estimate might be incorrect due to no delay signals. Therefore, bounding the loss based estimate by the delay based estimate is not much helpful in those cases.
Thus strengthening the bounding logic by using upper link capacity is one of solutions to avoid incorrect ramp-up.
Without the change: screen/qmLedxapJWvUTmn
With the change: screen/8sQcksWa6CptywK
Bug: webrtc:12707
Change-Id: I32ba82693b3ffa83cbb89c2cc9690fe16fb10c78
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283085
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38626}
Patchset 1 contrains the original cl.
Later patchsets contain fix.
Original description:
Continue probing if networkstat estimate increase
This fixes an issue where continues probing stops if networkstate estimate is low when a probe is sent, but increase as a consequence of the probe.
Bug: webrtc:14392
Change-Id: I8d4e1968020f9f8de18e12a4a0322a87f1a8fd2f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283082
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38612}
This reverts commit dd7dc25a30.
Reason for revert: Bug in CL. Continuously probe if experiment for probing based on the link capacity is enabled.
Original change's description:
> Continue probing if networkstat estimate increase
>
> This fixes an issue where continues probing stops if networkstate estimate is low when a probe is sent, but increase as a consequence of the probe.
>
>
> Bug: webrtc:14392
> Change-Id: Id1d703f7efc824a6a6f8d899c367660291bd88c8
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282941
> Reviewed-by: Diep Bui <diepbp@webrtc.org>
> Commit-Queue: Per Kjellander <perkj@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#38606}
Bug: webrtc:14392
Change-Id: Ib241b190951a78c436188c0b83d0247bf7d0dddd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283080
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#38609}
