From owner-freebsd-questions@FreeBSD.ORG Fri Apr 15 23:15:30 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C406016A4CE for ; Fri, 15 Apr 2005 23:15:30 +0000 (GMT) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CF5A43D3F for ; Fri, 15 Apr 2005 23:15:30 +0000 (GMT) (envelope-from list-freebsd-2004@morbius.sent.com) Received: from frontend2.messagingengine.com (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 23045C766FA for ; Fri, 15 Apr 2005 19:15:29 -0400 (EDT) X-Sasl-enc: Sgd//6F209Ci4YbDtRP53g 1113606927 Received: from gumby.localhost (dsl-80-41-66-32.access.as9105.com [80.41.66.32]) by frontend2.messagingengine.com (Postfix) with ESMTP id F19FC570147 for ; Fri, 15 Apr 2005 19:15:27 -0400 (EDT) From: RW To: freebsd-questions@freebsd.org Date: Sat, 16 Apr 2005 00:15:26 +0100 User-Agent: KMail/1.8 References: <20050414135309.B01C543D3F@mx1.FreeBSD.org> In-Reply-To: <20050414135309.B01C543D3F@mx1.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504160015.27096.list-freebsd-2004@morbius.sent.com> Subject: Re: Traffic Shapping (IPFW + DUMMYNET) Question X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 23:15:30 -0000 On Thursday 14 April 2005 14:53, Timothy Radigan wrote: > Hi all, > > I'm new to the entire idea of traffic shaping and I came up with some rules > for my BSD firewall/router/VoIP gateway > >... > > Does this seem like it will perform as I am thinking it will? I've not tried this kind of thing myself, but I wouldn't be very optimistic about what you are trying to do. AFAIK dummynet works through IP packet queueing. That means that it can do a good job of shaping outgoing traffic, but the only control it has on incoming traffic is through dropping packets that have already been received, which isn't very efficient. To achieve what you want would really need some something that can hook into the tcp/ip stack and affect tcp window sizes. I dont know of anything that would do that.