possible RFC6675 compute_pipe counting issue.

[Scheffenegger, Richard]

Hi Hiren,

I'm trying to reactivate my old Lost Retransmission Detection patch.

And I found your 2015 patch around sacked_bytes (RFC6675) here

https://github.com/rscheff/freebsd/commit/d3c29dd43ff23e293d5988258493015fb4a072ba

(The line ~389 in tcp_sack.c)

But I think the code is problematic in two reasons:

a) very thin clients, which may only send SACK deltas instead of full excerpts of the scoreboard (e.g. only a sack block covering the most recent received data)
b) whenever the receiver scoreboard has more discontinuous entries than what a single ACK can carry as SACK fields (typically 3, possibly 4 or as little as one).

However, these will overestimate the outstanding data (pipe).

(a) A cheating receiver sending multiple, identical sack blocks could game the sender, though, as the check is done on a ack sack block by block check, rather than when the scoreboard is updated...


Reason: Your patch only looks at the SACK data contained in the most recent ACK, rather than proper accounting of the non-sack holes in the scoreboard.

When I improved Aris PRR code, I did the accounting when the scoreboard is being updated; sacked_bytes need to exclude any snd.una move to the right, but should be similar:

https://github.com/rscheff/freebsd/commit/4a4877478fe55e8ebdfa0daf9a2be4b212d07cde


As PRR needs a proper value for the delivered delta bytes per ACK, it should be simple to keep track of the correct value for the SACKed bytes (not holes) in the scoreboard too...

Obviously, this can not be that much of an issue, as RFC6675 pipe is disabled by default, and would underestimate the number of sacked bytes at the receiver, unless the receiver has malicious intent...

Any thoughts?

Best regards,
  Richard