-
Notifications
You must be signed in to change notification settings - Fork 119
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: Path is not app limited if more data is available to transmit, with limits #1367
Conversation
…mited # Conflicts: # quic/s2n-quic-core/src/recovery/congestion_controller.rs
…mited # Conflicts: # quic/s2n-quic-transport/src/recovery/manager.rs # quic/s2n-quic-transport/src/recovery/manager/tests.rs # quic/s2n-quic-transport/src/space/application.rs # quic/s2n-quic-transport/src/space/handshake.rs # quic/s2n-quic-transport/src/space/initial.rs
self.delivered_bytes > app_limited_bytes | ||
}) | ||
{ | ||
// Clear app-limited field if bubble is ACKed and gone |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is bubble a term in BBR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It comes from the related delivery rate estimation draft RFC:
An application-limited phase starts when the sending application
requests to send new data, or the connection's retransmission
mechanisms decide to retransmit data, and the connection meets all of
the following conditions ...
If these conditions are all met then the sender has run out of data
to feed the network. This would effectively create a "bubble" of
idle time in the data pipeline.
This comment specifically is from the pseudocode: https://datatracker.ietf.org/doc/html/draft-cheng-iccrg-delivery-rate-estimation#section-3.3
…mited # Conflicts: # quic/s2n-quic-transport/src/space/application.rs
Description of changes:
This change re-introduces the changes from #1326, with additional limits on the maximum size the congestion window can grow to.
From the original description:
The original change would allow the congestion window to grow significantly, even if sending was blocked by flow control. This happened because if the pacer interrupts sending at a moment when sending is momentarily not blocked by flow control (after more flow control credit is received, for example), we will not be considered app-limited, and any acknowledgements received will increase the window.
This change introduces a
bytes_in_flight_hi
value to the Cubic congestion controller that tracks the highest value ofbytes_in_flight
seen since the last congestion event. The congestion window is not allowed to grow beyondbytes_in_flight_hi
multiplied by a multiplier (2.0 while in Slow Start and 1.5 in Congestion Avoidance).Testing:
Unit tests, tested on two EC2 hosts:
Before:
After:
Is this a refactor change? If so, how have you proved that the intended behavior hasn't changed? -->
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.