Skip to content

cc: trim OnTransportCCFeedback result to PacketStatusCount#414

Open
AnshulMalik wants to merge 1 commit intopion:mainfrom
AnshulMalik:fix-status-vector-chunk-padding
Open

cc: trim OnTransportCCFeedback result to PacketStatusCount#414
AnshulMalik wants to merge 1 commit intopion:mainfrom
AnshulMalik:fix-status-vector-chunk-padding

Conversation

@AnshulMalik
Copy link
Copy Markdown

StatusVectorChunks always encode a fixed number of slots (7 for 2-bit symbols, 14 for 1-bit). When the number of reported packets does not fill the final chunk, the encoder pads the remaining slots with TypeTCCPacketNotReceived symbols.

Without trimming, those padding slots are looked up in the send history and, if found (e.g. recently sent packets whose SNs happen to fall in the padding range), are returned as Acknowledgments with a zero Arrival time. The loss estimator then counts them as lost packets, inflating the loss estimate even though those packets are still in flight.

@codecov
Copy link
Copy Markdown

codecov Bot commented Apr 24, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.12%. Comparing base (c1e9f44) to head (97268a5).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #414      +/-   ##
==========================================
+ Coverage   80.07%   80.12%   +0.05%     
==========================================
  Files          88       88              
  Lines        4602     4604       +2     
==========================================
+ Hits         3685     3689       +4     
+ Misses        734      733       -1     
+ Partials      183      182       -1     
Flag Coverage Δ
go 80.12% <100.00%> (+0.05%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

StatusVectorChunks always encode a fixed number of slots (7
for 2-bit symbols, 14 for 1-bit). When the reported packet
count does not fill the final chunk, the encoder pads the
remaining slots with TypeTCCPacketNotReceived.

Without trimming, those padding slots are looked up in the
send history and, if found, returned as Acknowledgments with
zero Arrival time. The loss estimator then counts them as
lost packets, inflating the loss estimate even though those
packets are still in flight.

Fix by truncating the result to PacketStatusCount after
processing all chunks, which is the authoritative count of
packets the feedback actually covers.
@AnshulMalik AnshulMalik force-pushed the fix-status-vector-chunk-padding branch from c557388 to 97268a5 Compare April 24, 2026 10:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant