recovery: floor loss delay at observed ack latency - #2568
Open
davidtorcivia wants to merge 2 commits into
Open
Conversation
Acknowledgements are processed in batches and the RTT estimate only samples the freshest packet of each batch. On a path whose RTT is close to or below the granularity of ack processing, the time and packet thresholds declare packets lost whose acknowledgements have not had a chance to be processed yet. Each spurious declaration triggers a retransmission and a congestion event for a packet that was delivered. This adds a config option, off by default, that floors the loss delay at the slowest send-to-processed-ack loop observed in the last 512ms, and applies the packet reordering threshold only to packets older than that loop. Both recovery implementations are covered. Measured on a 10GbE path with 0.2-0.6ms RTT, six connections carrying 1GB with CUBIC: declared losses fell from 25-30k per run to 1.3-2.3k, acks that disproved a declaration fell from 8-10k to 100-200, and goodput rose from 7.9 to 8.8 Gbit/s median over five runs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Acknowledgements are processed in batches and the RTT estimate only samples the freshest packet of each batch. On a path whose RTT is close to or below the granularity of ack processing, the time and packet thresholds declare packets lost whose acknowledgements have not had a chance to be processed yet. Each spurious declaration triggers a retransmission and a congestion event for a packet that was delivered.
This adds
enable_ack_latency_loss_floor, off by default. When enabled, the loss delay is floored at the slowest send-to-processed-ack loop observed in the last 512ms, and the packet reordering threshold only applies to packets older than that loop. Both recovery implementations are covered. Behavior with the flag off is unchanged.Testing
New tests in
recovery/mod.rsrun against reno, cubic, bbr2 and bbr2_gcongestion: a late ack batch no longer convicts packets younger than the observed loop, and time based detection still fires once a packet outlives the floored delay.Measured on a 10GbE path with 0.2-0.6ms RTT, six connections carrying 1GB per run with CUBIC, five runs per arm: declared losses fell from 25-30k per run to 1.3-2.3k, spurious losses (declared and later acked) fell from 8-10k to 100-200, and goodput rose from 7.9 to 8.8 Gbit/s median. Packet captures at the receiver NIC showed zero actual path loss in both arms, so the declarations were detector artifacts.