Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(s2n-quic-core): support higher bandwidth estimates #1650

Merged
merged 2 commits into from
Mar 2, 2023

Conversation

WesleyRosenblum
Copy link
Contributor

Resolved issues:

resolves #1440

Description of changes:

The current representation of a bandwidth estimate used mostly by BBR (but also for CUBIC pacing) can support a maximum bandwidth of 1GB/sec. This may not be sufficient for data center usage, so this change allows for support up to ~1TB/sec.

Call-outs:

Many snapshot tests changed slightly, this is due to the new code storing bandwidth more precisely.

Testing:

Updated and added some tests

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@@ -2,4 +2,4 @@
source: quic/s2n-quic-core/src/recovery/bbr/pacing.rs
expression: ""
---
PacingRateUpdated { path_id: 0, bytes_per_second: 2747252, burst_size: 12000, pacing_gain: 2.77 }
PacingRateUpdated { path_id: 0, bytes_per_second: 2742301, burst_size: 12000, pacing_gain: 2.77 }
Copy link
Contributor

@camshaft camshaft Mar 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that all of these estimates are rounding down. This one is the most extreme with ~5000 bytes. I'm not sure it's a huge cause for concern but it could mean that we're not sending as fast since we're underestimating the bandwidth, right? Or were we overestimating before?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah we were overestimating before. The math previously would be

(1000/ 2.77)/.99 = 364.657 nanos/byte, which truncates to 364 nanos/byte = 2747252 bytes/sec

Now the math is:

1000 * 1024 / 2.77 / .99 = 373409.182 nanos/kibibyte, which truncates to 373409 nanos/kibibyte = 2742301 bytes/sec

@WesleyRosenblum WesleyRosenblum merged commit ddccbed into main Mar 2, 2023
@WesleyRosenblum WesleyRosenblum deleted the WesleyRosenblum/bandwidthmax branch March 2, 2023 19:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BBRv2 bandwidth estimation is limited to 1GB/sec
2 participants