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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[email protected]"
