Page MenuHomeFreeBSD

Receiver Side DSACK (RFC2883) implementation
ClosedPublic

Authored by rscheff_gmx.at on Feb 24 2019, 9:46 PM.

Details

Summary

Initial DSACK implementation, including partial overlaps per RFC2883

For incoming data segments, if they are duplicate or overlap already
received data, send out a DSACK block as the 1st SACK block, indicating
the overlap.

Does not send DSACK block on cummulative ACKs, even when the segment
with all the outstanding data overlaps left or right with already
received data.

If overlaps exist deeper into the sackblk array, may not coalesce these
properly.

The common case, with equal sized segments and identical segment
boundaries works as per RFC2883.

Test Plan

see DSACK packetdrill script

Diff Detail

Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 22697
Build 21796: arc lint + arc unit

Event Timeline

rscheff_gmx.at created this revision.Feb 24 2019, 9:46 PM

packetdrill test script

Note that a few cornercases therein track the code, not what nominally is RFC2883 compliant

Overlaps on left & right report the right overlap, not the left;
A full ACK will clear any sack report, rather than provide DSACK blocks of partial overlap.

rrs accepted this revision.Mar 27 2019, 4:09 PM
This revision is now accepted and ready to land.Mar 27 2019, 4:09 PM

Need to look into RACK stack and apply similar changes.

sys/netinet/tcp_input.c
2261

After discussing this, segements up here should be silently discarded - removing this diff block before applying diff.

Ready to land.

sys/netinet/tcp_input.c
2261

Looked at this again - here we are not in a TS PAWS drop, by an old segment beneath rcv_nxt. This is the instance which should regularly issue DSACK blocks.

This revision was automatically updated to reflect the committed changes.