From owner-freebsd-ipfw@FreeBSD.ORG Tue Jun 12 23:49:05 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7006116A400 for ; Tue, 12 Jun 2007 23:49:05 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id 58F2813C457 for ; Tue, 12 Jun 2007 23:49:05 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out4.apple.com (Postfix) with ESMTP id 246078D9014; Tue, 12 Jun 2007 16:49:05 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id 131D0100BE; Tue, 12 Jun 2007 16:49:05 -0700 (PDT) X-AuditID: 11807124-a26cbbb000000801-6c-466f30f1c27e Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay6.apple.com (Apple SCV relay) with ESMTP id 04D6E10081; Tue, 12 Jun 2007 16:49:05 -0700 (PDT) In-Reply-To: <937e203f0706121636q35b53d30x408b6caa080ecff6@mail.gmail.com> References: <937e203f0706121636q35b53d30x408b6caa080ecff6@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49236B54-3235-4F8F-A79A-C023EF0E54A4@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Tue, 12 Jun 2007 16:49:04 -0700 To: Lubomir Georgiev <0shady0recs0@gmail.com> X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw, pipes, queues, weights and managing an Internet connection X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 23:49:05 -0000 On Jun 12, 2007, at 4:36 PM, Lubomir Georgiev wrote: > OK, so that answers my question.... I'm just stupid :D You just need to read the fine manual. :-) > Just one question - you're saying that it is possible to shape / > delay, > drop etc./ the packets so quickly so that when a pipe is fully > utilized > someone hits a queue with a higher weight /for example port 80 > would be > prioritized over p2p traffic/ it would be like as if the pipe was > not used > at all? I don't believe that I can answer this better than the existing description: Packets belonging to the same flow are then passed to either of two different objects, which implement the traffic regulation: pipe A pipe emulates a link with given bandwidth, propagation delay, queue size and packet loss rate. Packets are queued in front of the pipe as they come out from the classifier, and then transferred to the pipe according to the pipe's parameters. queue A queue is an abstraction used to implement the WF2Q+ (Worst- case Fair Weighted Fair Queueing) policy, which is an effi- cient variant of the WFQ policy. The queue associates a weight and a reference pipe to each flow, and then all backlogged (i.e., with packets queued) flows linked to the same pipe share the pipe's bandwidth pro- portionally to their weights. Note that weights are not pri- orities; a flow with a lower weight is still guaranteed to get its fraction of the bandwidth even if a flow with a higher weight is permanently backlogged. In practice, pipes can be used to set hard limits to the bandwidth that a flow can use, whereas queues can be used to determine how different flows share the available bandwidth. -- -Chuck