Add transport setting to cap additional ACK blocks per ACK frame#461
Open
UditDewan wants to merge 1 commit into
Open
Add transport setting to cap additional ACK blocks per ACK frame#461UditDewan wants to merge 1 commit into
UditDewan wants to merge 1 commit into
Conversation
On lossy networks, workloads that never retransmit lost packet numbers (e.g. QUIC datagrams) accumulate ack ranges faster than they coalesce, so ACK frames grow until they fill the packet and can consume significant bandwidth relative to the application data. Add transportSettings.maxAdditionalAckBlocksPerFrame to bound the number of additional ack blocks (beyond the required first block) written into each ACK frame. The blocks covering the most recent packet numbers are kept. Defaults to unlimited, preserving existing behavior. The cap applies to all ACK frame variants (ACK, ACK_ECN, ACK_RECEIVE_TIMESTAMPS, ACK_EXTENDED, and draft-02) since they share the same base-field writer. Fixes facebook#357
meta-cla
Bot
added
the
CLA Signed
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.
Summary
There is currently no way to bound the number of ack blocks written into an ACK frame. As described in #357, datagram-heavy workloads on lossy networks accumulate ack ranges that are never coalesced (lost packet numbers are never retransmitted), so ACK frames grow until they fill the packet and can consume significant bandwidth relative to the application payload (frames over 1000 bytes were observed with sub-100-byte datagrams).
This adds
transportSettings.maxAdditionalAckBlocksPerFrame, which caps the number of additional ack blocks (beyond the required first block) written into each outgoing ACK frame:fillFrameWithAckBlocks, the single choke point shared by all ACK variants (ACK,ACK_ECN,ACK_RECEIVE_TIMESTAMPS,ACK_EXTENDED, and the draft-02 receive-timestamps frames), so it applies uniformly.Per RFC 9000 §13.2.3, a receiver may limit the number of ACK Ranges it reports, so a capped frame remains fully spec-compliant.
Fixes #357
Test Plan
Added
QuicWriteCodecTest.WriteAckFrameWithMaxAdditionalAckBlocks: writes 30 ack blocks with the cap set to 3 and verifies via encode + decode round trip that exactly 4 blocks (first + 3 additional) covering the most recent packet numbers are emitted.