TCP SACK

[Lawrence Stewart]

Learner Study wrote:
> Hello experts:
> 
> Is there is reason why freebsd TCP implementation limits the number of SACK
> blocks on receiver side to MAX_SACK_BLOCKS whereas the sender side SACK
> holes are implemented as a linked list?
> 
> Any issues if someone decides to use receiver side linked list as well
> (instead of fixed sized array)?

I'm not intimately familiar with the SACK code, so with that disclaimer 
in hand...

For starters, there is a limit imposed by the TCP option space on the 
number of SACK blocks you can squeeze into a single TCP header (max 4, 
typically fewer when other common options are in use). MAX_SACK_BLKS is 
defined as 6, so we actually are able to store an extra 2 blocks 
receiver side than we can send in any given ACK.

Given that constraint, I see no reason to store more blocks at the 
receiver. As holes get filled, we recompute the sack blocks anyway so I 
don't think (conceptually at least) we're losing any important 
information. I am aware though that the implementation is sub-optimal in 
other areas (a few of which I'm trying to fix).

That said, I see no issues with switching to a linked list. You'd need 
to do some replumbing around the place and you will increase memory 
consumption for I suspect will be no real gain.

If you decide to proceed and can measure improvements as a result of 
your changes, I'd be interested to look at your patch(es). I just 
suspect it will be a relatively fruitless endeavor.

Cheers,
Lawrence