Date: Mon, 14 Nov 2011 08:40:44 +1100 From: grenville armitage <garmitage@swin.edu.au> To: freebsd-net@freebsd.org Subject: Re: Arg. TCP slow start killing me. Message-ID: <4EC0395C.3030302@swin.edu.au> In-Reply-To: <4EC033B7.5080609@soe.ucsc.edu> References: <4EC033B7.5080609@soe.ucsc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EC0395C.3030302>