Summary: Several "Network Path Model" parameters are described in Sec. 2.9 of the BBRv2 IETF draft. These quantities evolve throughout the connection and they are useful to analyze BBRv2 performance. This diff adds inflight_hi, inflight_lo, bandwidth_hi, and bandwidth_lo to the qlog.
Reviewed By: mjoras
Differential Revision: D61414936
fbshipit-source-id: 2862db2a6aab336fd8a60e4ae5b358e9ab5588b4
Summary: This matches our BBRv1 implementation, and also what Google does. Pacing the initial congestion window is likely overly conservative, so add a knob to test it.
Reviewed By: kvtsoy
Differential Revision: D61295575
fbshipit-source-id: 63599ecabccec8f6e358b013a1e5384d1198e5d1
Summary:
The idea here is to make it so we can swap out the type we are using for optionality. In the near term we are going to try swapping towards one that more aggressively tries to save size.
For now there is no functional change and this is just a big aliasing diff.
Reviewed By: sharmafb
Differential Revision: D57633896
fbshipit-source-id: 6eae5953d47395b390016e59cf9d639f3b6c8cfe
Summary: As title. There are so many unnecessary bandwidth estimate updates in bbrv2 qlogs.
Reviewed By: mjoras
Differential Revision: D57783116
fbshipit-source-id: afeaa89d03c8c2f6f63ceb852790bb8706f46812
Summary:
1. Noticed that bbr2 was not discovering the available BtlBw because it exited startup early due to loss. Disabling packet conservation seems to help, in sims. bbr1 has conservativeRecovery flag set to false by default. In the same spirit, we should enable/disable packet conservation in bbr2 based on that flag.
2. The CWND is decreased by the loss amount. This should be disabled when ignoreLoss is true.
Reviewed By: jbeshay, mjoras
Differential Revision: D55612685
fbshipit-source-id: 0c811de78e4a6f273f340631d29ff9dcd27d898e
Summary:
The exact semantics of entering and leaving the app limited state are currently maintained by the congestion controller, therefore the qlog events have to be logged there.
This change logs app limited events from bbr2.
Reviewed By: sharmafb
Differential Revision: D55429423
fbshipit-source-id: 582252ab715411c65da25721107de52f01e59754
Summary: If the connection goes idle (inflight bytes=0), there is no point in waiting for the rest of the probe rtt minimum duration. This change allows it to exit early.
Reviewed By: kvtsoy, sharmafb
Differential Revision: D55395803
fbshipit-source-id: 43e68120529e22ddfe7cc5a8a17091e952c958f9
Summary: This simplifies the logic for ignoring the short term and long term loss thresholds on bbr2 (Lo_ and Hi_ variables).
Reviewed By: mjoras
Differential Revision: D54697605
fbshipit-source-id: 44cd91974a20f267f1986542f8b993795287fe4d
Summary:
ProbeBW_Up is the phase that probes for avaialable bandiwdth after BBRv2 has exited startup.
Previously, by using inflightLatest and having a strict equality check on being cwndLimited, ProbeBw_Up was not able to effectively probe for bandwidth.
This change improves BBRv2's ability to probe for bandwidth within one ProbeBW cycle from the capacity being available.
Reviewed By: mjoras
Differential Revision: D53597316
fbshipit-source-id: ce666417ac110ded1860fc4309a807c51c4a7566
Summary: Our current pacer achieves roughly 99% of the target pace. While we decide how to improve that, we should not leave more pacing margin in bbr2.
Reviewed By: mjoras
Differential Revision: D53586406
fbshipit-source-id: da4b9c22458792aa9266bcf7371b13f68f16d8d0
Summary:
Reno-coexistence forces bbr2 to terminate ProbeBW cycles early. When competing with other CCAs, this can cause bbr2 to back off rather than probe for more bandwidth because it advances the probe bw cycle count.
This change adds an options to control whether that is used.
Reviewed By: mjoras
Differential Revision: D53586408
fbshipit-source-id: 14fccc1aaaeb96dfc30f2e8df68c69d75d52a329
Summary:
Updating the cycle count in adaptUpperBounds() mean that it could happen prematurely if ProbeBw_Down lasts longer than a single round (rtt round).
This changes the logic to advance the ProbeBW cycle only when entering ProbeBw_Down. It also removes the advanceCycleAfterStartup option which is now irrelevant.
This results in better coexistence with loss-based CCAs.
Reviewed By: mjoras
Differential Revision: D53586407
fbshipit-source-id: fdc7ac23184e4edebb74f10026acb821f9df34f9
Summary: This was outright wrong. We need to wait 2-3 seconds.
Reviewed By: mjoras
Differential Revision: D53500129
fbshipit-source-id: bc270c950076919fd4fe8dbeb1b12c2d19d7ae15
Summary:
BBRv2's bandwidth filter carries over the bandwidth sample from the Startup phase into probe bandwidth, without updating the cycle count. This delays the reaction to bandwidth changes by an additional probe bw cycle.
This change adds an option to count Startup as its own cycle in the bandwidth filter. It's defaulted to true.
Reviewed By: mjoras
Differential Revision: D50146879
fbshipit-source-id: 0b5b3a90171828848653b655dabc0133fa275583
Summary:
The window_length parameter in the WindowedFilter is enforced by checking the distance between new sample and the old one is greater than the window length.
For BBRv2 max bandwidth filter, the timestamp is the integer cycle count number. Effectively the max value becomes the maximum of window+1 cycles.
This change compensates for that logic by subtracting 1 from the window length.
Reviewed By: mjoras
Differential Revision: D50136527
fbshipit-source-id: fd8a7bc444895e486f0a707c7aa2888ae1213083
Summary: bandwidthHi_ and inflightHi_ should only be set after loss has occured.
Reviewed By: mjoras
Differential Revision: D49784760
fbshipit-source-id: 99bfb98a7d07849e10fb89aaccf5ff51437d400b
Summary:
When BBR2 switches from Startup to Drain, it starts applying a limit on pacing using bandwidthHi_. If this transition happens around an idleRestart, populating bandwidthHi_ from bandwidthLatest only, can result in lower samples that underutilize the link.
This change ensures that transitioning from Startup to Drain maintains the pacing rate.
Reviewed By: mjoras
Differential Revision: D49550971
fbshipit-source-id: 8f2644e8636382bc3498b3ec9c82e98cd15aa6d2
Summary: When restarting from idle, the probeRTT min value can be updated without having to enter ProbeRTT.
Reviewed By: mjoras
Differential Revision: D49548502
fbshipit-source-id: 8471df3e15eb788b087764f2630537c71e164914
Summary:
inflightHi currently forces the cwnd to be very close to the target BDP even during ProbeBW, this can slow down the ProbeBW_UP attempting to probe for more bandwidth.
Reaction to packet loss is a core difference between BBRv1 and BBRv2.
This adds a couple of cca config options to enable experimenting with both and compare specific parts of BBRv2 behavior in comparison to BBRv1.
Reviewed By: mjoras
Differential Revision: D49526118
fbshipit-source-id: 35ba83e834b1febd79c0e46af39b0205cde4dc1c
Summary:
Previously extraAckedDelivered was not reset for every train of packets so it could keep increasing and pushing the congestion window higher while in startup.
This did not have an impact on the speed the pacekts are sent because pacing was still only controlled by the bandwidth estimate_ but this could be visibile in the divergence between the cwnd and target pacing rate.
Reviewed By: hanidamlaj
Differential Revision: D49286012
fbshipit-source-id: 1340c939fde6b35e3edfefd248b52396c4c3195f
Summary:
Change inflightHi_ and inflightLo_ into optionals to makes it easier to distinguish between an initial value and not having a value.
Change inflightMax into a local variable.
Set initial value for sendQuantum_ and extraAckedDelivered_.
Change bwProbeSamples_ to a boolean bwProbeShouldHandleLoss_ so it's more descriptive.
Differential Revision: D48654867
fbshipit-source-id: 5447d4cd15f25391fa986ecf70bc08b3662070d8
Summary:
The draft description mentions the max bw filter using the probe bw cycle count, but the pseudo code was using the round count. This change makes it match the description rather than the pseudo code. This fixes the situation where the pacing margin leads to a downward spiral in the target pacing rate (lower pacing rate -> lower bw estimate -> lower pacing rate -> etc.).
Also, the ack phase is not used so removing it.
Reviewed By: mjoras
Differential Revision: D46974994
fbshipit-source-id: 7936183e5cd10a75f88ede33045d7f4461fc27e0
Summary:
This implements the BBRv2 congestion controller for Mvfst. This implementation aims at staying as close as possible to the naming and organization used in the latest draft. Wherever there are gaps in the spec or the pseudocode, this attempts to fill them with reasonable assumptions.
https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control-02
Besides the spec differences, this implementation differs from Mvfst's BBRv1 as follows. These differences may be revisited in the future:
- The pacing rate is exclusively controlled by the CCA. No further scaling of the pacer rate is enforced. This enables BBRv2 control loop to keep tight control over queueing delay.
- BBRv2 does not rely on an external bandwidth or RTT sampler. Mvfst's BBRv1 decouples these which makes tracking the state a bit harder.
Reviewed By: mjoras
Differential Revision: D44599226
fbshipit-source-id: 1e488bd936db5826b73ff6205f988dd40e908eba
