From owner-freebsd-pf@FreeBSD.ORG Thu Feb 12 09:26:41 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F9E0106566C for ; Thu, 12 Feb 2009 09:26:41 +0000 (UTC) (envelope-from tom@uffner.com) Received: from eris.uffner.com (eris.uffner.com [207.245.121.212]) by mx1.freebsd.org (Postfix) with ESMTP id 4B2E68FC28 for ; Thu, 12 Feb 2009 09:26:41 +0000 (UTC) (envelope-from tom@uffner.com) Received: from xiombarg.uffner.com (static-71-162-143-94.phlapa.fios.verizon.net [71.162.143.94]) (authenticated bits=0) by eris.uffner.com (8.14.3/8.14.3) with ESMTP id n1C9QQhc024991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Feb 2009 04:26:27 -0500 (EST) (envelope-from tom@uffner.com) Message-ID: <4993EB42.2020503@uffner.com> Date: Thu, 12 Feb 2009 04:26:26 -0500 From: Tom Uffner User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.19) Gecko/20090125 SeaMonkey/1.1.14 MIME-Version: 1.0 To: eculp References: <76463C1E8CB14B958088F7E54C611560@ashevchenko> <493634DA.7000408@infoweapons.com> <20081203071940.324735uokbfgyh6o@econet.encontacto.net> In-Reply-To: <20081203071940.324735uokbfgyh6o@econet.encontacto.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/8978/Wed Feb 11 00:29:20 2009 on eris.uffner.com X-Virus-Status: Clean Cc: freebsd-pf@freebsd.org Subject: Re: PF + ALTQ - Bandwidth per customer X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 09:26:41 -0000 eculp wrote: > I don't remember why but for some reason I have the idea that pf+altq is > not bidirectional. Am I mistaken? no solution that does not involve cooperation from your upstream connection(s) is truly bidirectional. it is easy to limit/shape your outbound traffic. on the other hand it is difficult if not impossible to unilaterally control the amount or sources of inbound data arriving at your border router(s) on it's way to various applications (mail servers, for example). you can _pretend_ to by dropping, queuing or otherwise limiting it once inside your network, but you cannot meaningfully prevent it from using your downlink bandwidth and potentially crowding out other, possibly more desirable, inbound data.