From owner-freebsd-net@FreeBSD.ORG Sun Nov 13 22:45:03 2011 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 15F9E106566B for ; Sun, 13 Nov 2011 22:45:03 +0000 (UTC) (envelope-from garmitage@swin.edu.au) Received: from gpo4.cc.swin.edu.au (gpo4.cc.swin.edu.au [136.186.1.33]) by mx1.freebsd.org (Postfix) with ESMTP id A12448FC08 for ; Sun, 13 Nov 2011 22:45:02 +0000 (UTC) Received: from [136.186.229.44] (garmitage3.caia.swin.edu.au [136.186.229.44]) by gpo4.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id pADLei1o011180 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2011 08:40:54 +1100 Message-ID: <4EC0395C.3030302@swin.edu.au> Date: Mon, 14 Nov 2011 08:40:44 +1100 From: grenville armitage User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101211 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4EC033B7.5080609@soe.ucsc.edu> In-Reply-To: <4EC033B7.5080609@soe.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Arg. TCP slow start killing me. 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: Sun, 13 Nov 2011 22:45:03 -0000 On 11/14/2011 08:16, Erich Weiler wrote: > So, I have a FreeBSD 8.1 box that I'm using as a firewall (pfSense > 2.0 really, which uses 8.1 as a base), and I'm filtering packets > inbound and I'm seeing a typical sawtooth pattern where I get high > bandwidth, then a packet drops somewhere, and the TCP connections > back off a *lot*, then slowly get faster, then backoff, etc. These > are all higher latency WAN connections. [..] > Any help much appreciated! I'm probably missing a key point, but > that's why I'm posting to the list. ;) Possibly not much you can do if you only have control of a firewall. (And it sounds like your firewall is neither the TCP source or destination.) A TCP sender pretty much dictates how it will react to packet loss (so the senders are the ones who need to explore the use of e.g. cubic). Now, if it is your firewall that's causing some of the packet losses, then you can help by increasing buffering locally -- but that's only to avoid the overflow that causes packets to be lost. If your firewall isn't the cause of the packet losses, then you don't really have much control -- the TCP source(s) _will_ detect the packet losses, either due to duplicate ACKs coming back from the destination or timeout waiting for ACK from destination. Adding buffering on the firewall wont help here either -- unless you artificially rate-limit flows through the firewall (e.g. with dummynet) there's little reason for a queue to build up, and if you enforce a queue (more latency) the path's RTT will be artificially high, causing much badness (reduced goodput) for all TCP sessions passing through your firewall. cheers, gja