Page MenuHomeFreeBSD

Stop sending tiny new data segments during SACK recovery
ClosedPublic

Authored by rscheff on Sep 15 2020, 8:46 PM.
Tags
None
Referenced Files
F106141578: D26446.diff
Thu, Dec 26, 2:15 AM
Unknown Object (File)
Sun, Dec 22, 7:11 PM
Unknown Object (File)
Sun, Dec 22, 1:52 AM
Unknown Object (File)
Wed, Dec 4, 4:21 PM
Unknown Object (File)
Nov 25 2024, 8:46 PM
Unknown Object (File)
Nov 22 2024, 8:24 PM
Unknown Object (File)
Nov 22 2024, 2:26 PM
Unknown Object (File)
Nov 21 2024, 9:01 AM
Subscribers

Details

Summary

When processing a partial acknowledgment during SACK
loss recovery, the size of the TCP option (in particular,
the timestamp option) was not considered properly.

This would restict the amount of new data to be injected,
but also could lead to the transmission of segments with
little data (a multiple of 12 bytes).

Considering the currently in-use TCP options when
calculating the amount of new data to be injected will
address this issue.

Reported-by: Liang Tian

Test Plan

Establish a TCP session with both SACK and Timestamps
enabled (the vast majority of all sessions in use today).

Simulate two or more non-consecutive packet drops within
a window and validate that new data is no longer injected
with very small segments, provided that the send buffer
is sufficiently full.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 34073
Build 31254: arc lint + arc unit

Event Timeline

This revision is now accepted and ready to land.Oct 8 2020, 1:03 PM
cc requested changes to this revision.Oct 8 2020, 3:13 PM
cc added inline comments.
sys/netinet/tcp_sack.c
790

Better use the type u_int for maxseg.

This revision now requires changes to proceed.Oct 8 2020, 3:13 PM
  • make maxseg u_int,
  • fix tcpstat accounting for sack,
  • remove redundant conditional check
This revision was not accepted when it landed; it landed in state Needs Review.Oct 9 2020, 12:45 PM
This revision was automatically updated to reflect the committed changes.