From owner-freebsd-net@FreeBSD.ORG Wed Jul 22 09:11:26 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60F6B106566B for ; Wed, 22 Jul 2009 09:11:26 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id E8AB18FC17 for ; Wed, 22 Jul 2009 09:11:25 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart-laptop.caia.swin.edu.au (host86-144-70-159.range86-144.btcentralplus.com [86.144.70.159]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n6M9BDEm013073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 19:11:16 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4A66D799.5050307@freebsd.org> Date: Wed, 22 Jul 2009 10:10:49 +0100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Learner Study References: <7efa8a7d0907210207m327a1252nee4a04f5e4ea7a@mail.gmail.com> In-Reply-To: <7efa8a7d0907210207m327a1252nee4a04f5e4ea7a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: freebsd-net@freebsd.org Subject: Re: TCP SACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 09:11:26 -0000 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