Page MenuHomeFreeBSD

tcp: Rack at times can miscalculate the RTT from what it thinks is a persists probe respone.
ClosedPublic

Authored by rrs on Oct 28 2021, 7:54 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, May 5, 9:11 AM
Unknown Object (File)
Thu, May 2, 12:38 PM
Unknown Object (File)
Sun, Apr 28, 6:19 PM
Unknown Object (File)
Sun, Apr 28, 2:18 AM
Unknown Object (File)
Sat, Apr 27, 10:27 AM
Unknown Object (File)
Sat, Apr 27, 10:27 AM
Unknown Object (File)
Sat, Apr 27, 10:27 AM
Unknown Object (File)
Sat, Apr 27, 10:27 AM
Subscribers

Details

Summary

Turns out that if a peer sends in a window update right after rack fires off
a persists probe, we can mis-interpret the window update and calculate
a bogus RTT (very short). We still process the window update and send
the data but we incorrectly generate an RTT. We should be only doing
the RTT stuff if the rwnd is still small and has not changed.

Test Plan

We can use packet drill to generate the situation but will have to
examine the BB logs to validate that the invalid RTT measurement
is not made.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

rrs requested review of this revision.Oct 28 2021, 7:54 PM
This revision is now accepted and ready to land.Oct 28 2021, 8:11 PM

Opps there is another issue here, a double bump of rtt_shift that should not be when persists happen. Only
bump it in the timer code.

This revision now requires review to proceed.Oct 28 2021, 8:19 PM
This revision is now accepted and ready to land.Oct 28 2021, 8:28 PM