Date: Wed, 22 Jul 2009 10:10:49 +0100 From: Lawrence Stewart <lstewart@freebsd.org> To: Learner Study <learner.study@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: TCP SACK Message-ID: <4A66D799.5050307@freebsd.org> In-Reply-To: <7efa8a7d0907210207m327a1252nee4a04f5e4ea7a@mail.gmail.com> References: <7efa8a7d0907210207m327a1252nee4a04f5e4ea7a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A66D799.5050307>