From owner-freebsd-net@FreeBSD.ORG  Sun Nov 13 23:42:05 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 E9ED0106566C
	for <freebsd-net@freebsd.org>; Sun, 13 Nov 2011 23:42:03 +0000 (UTC)
	(envelope-from weiler@soe.ucsc.edu)
Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32])
	by mx1.freebsd.org (Postfix) with ESMTP id D8C728FC08
	for <freebsd-net@freebsd.org>; Sun, 13 Nov 2011 23:42:03 +0000 (UTC)
Received: from erich-weilers-macbook-pro.local
	(dsl-63-249-90-171.static.cruzio.com [63.249.90.171])
	by mail-01.cse.ucsc.edu (Postfix) with ESMTPSA id 70D284E44052;
	Sun, 13 Nov 2011 15:42:03 -0800 (PST)
Message-ID: <4EC055CB.40100@soe.ucsc.edu>
Date: Sun, 13 Nov 2011 15:42:03 -0800
From: Erich Weiler <weiler@soe.ucsc.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: grenville armitage <garmitage@swin.edu.au>
References: <4EC033B7.5080609@soe.ucsc.edu> <4EC0395C.3030302@swin.edu.au>
In-Reply-To: <4EC0395C.3030302@swin.edu.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Nov 2011 23:42:05 -0000


> 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.

I suspect my firewall *is* the cause of the packet loss, unfortunately. 
  We're sending multiple streams in from multiple sources and 
destinations, but the aggregate bandwidth coming into the firewall is 
consistent no matter how many sources and destinations we have.  It 
maxes at about 2Gb/s.  That's why I was trying to tweak the firewall, to 
try and get that number up.