RFC6675, the update to SACK loss recovery (RFC3517), has the following new features:
- an improved pipe calculation, which was already partially implemented*
- an improved logic, when to enter Loss Recovery
- as icing on the cake, RescueRetransmission was added
With RFC6675, each independed SACK block, and each SMSS number of data SACKed, are considered for the purpose of having crossed the DupThresh threshold.
E.g. unlike before, where 3 independent duplicate ACKs were required (4 ACKs with the same Acknowledgement number), even the first DupACK seen could start
loss recovery, provided the SACK information contained indicates that more than 2 MSS blocks were received (2 MSS + 1 byte, spanning at least 3 different
Especially in situations where the return path exhibits high (ACK) loss rates ("ACK thinning"), this can help starting loss recovery more timely.
The RescueRetransmission is a feature in particular for use in Request-Response type of traffic, where additional data may only be made available to TCP,
after all the previous data has been delivered in full to the client. This pattern is prevalent in IO (storage, e.g. NFS) environments. While at the end
of loss recovery (all known missing data has been retransmitted, but no SACK block covering Recovery was receives, and no additional data is available to
send), the sender will transmit the very last segment once more, if possible. If a burst loss happend to drop a 1 or more packets just left to snd_max,
without this feature TCP has to revert to RTO to recover from such a situation.
- The prior rfc6675_pipe calculation only considered data received in the last SACK option. For more than (typically) 3 seperate losses in a window, the
TCP option itself does not the entire relevant data. D18624 addresses this, and provides additional state data relevant for PRR too.
This Patch also contains D18624, as RFC6675 makes use of many of these SACK state variables, and they should be calculated properly.
All changes use the sysctl "rfc6675_pipe" for now.