From owner-freebsd-net Tue May 1 14:56:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62]) by hub.freebsd.org (Postfix) with ESMTP id E618237B422 for ; Tue, 1 May 2001 14:56:28 -0700 (PDT) (envelope-from rguyom@pobox.com) Received: from diabolic-cow.chatgris.net (dyn-1-1-028.Orl.dialup.oleane.fr [195.25.26.28]) by smtp4.cluster.oleane.net with ESMTP id f41Lu9f08943; Tue, 1 May 2001 23:56:10 +0200 (CEST) Received: by diabolic-cow.chatgris.net (Postfix, from userid 1000) id 8BC45266; Tue, 1 May 2001 23:56:02 +0200 (CEST) Date: Tue, 1 May 2001 23:56:02 +0200 From: =?iso-8859-1?Q?R=E9mi_Guyomarch?= To: Gunther Schadow Cc: snap-users@kame.net, freebsd-net@freebsd.org, ipfilter@coombs.anu.edu.au, altq@csl.sony.co.jp Subject: Re: The future of ALTQ, IPsec & IPFILTER playing together ... Message-ID: <20010501235602.B30269@diabolic-cow.chatgris.net> References: <3AEEEE79.8F7CC7B0@aurora.regenstrief.org> <3AEEF26B.C6850070@isi.edu> <3AEEF59D.3D5622DE@aurora.regenstrief.org> <20010501205741.A30269@diabolic-cow.chatgris.net> <3AEF0E6A.2E9B34A0@aurora.regenstrief.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <3AEF0E6A.2E9B34A0@aurora.regenstrief.org>; from gunther@aurora.regenstrief.org on Tue, May 01, 2001 at 07:28:42PM +0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, May 01, 2001 at 07:28:42PM +0000, Gunther Schadow wrote: > Rémi Guyomarch wrote: > > > IIRC you can put a bandwidth limiter on a virtual interface (this is > > even the only solution to use ALTQ on tun or ppp devices) and thus > > provide a queue which can be managed by ALTQ. > > Aha! A Light! How is that done? Can you give more specifics? Look at docs/TIPS.txt in the altq-3.0 release, point 1.9 : ... 1.9 Tun Driver Although altq-3.0 supports the tun driver, it is a bit tricky to control the tun device. When ppp transmits packets the tun interface is not a bottleneck but the serial port is the bottleneck. As a result, packets are queued in the output queue of ppp and the buffer in the kernel as shown in the following figure. (a queued packet is shown as X.) ppp app ---+ +-->[ XXX]--+ | | | user | | | ==========|==============|===========|===== kernel | | | | +------+ | | +-->| |---+ +->[ XX]--> sio +------+ line tun0 discipline To control traffic at the tun interface, rate-limit the tun interface by a token-bucket regulator to shift the queueing point to the tun device as shown in the following figure. ppp app ---+ +-->[ ]--+ | | | user | | | ==========|==============|===========|===== kernel | | | | +------+ | | +-->| XXXXX|---+ +->[ ]--> sio +------+^tbr line tun0 discipline Note that ppp usually compress packets so that the throughput at the tun interface will be much higher than the line rate. ... You should put a token-bucket regulator (TBR) on tun0 and then add a queueing discipline on this virtual interface. This is ok (tbr + queueing discipline on tun0) unless you also have non-tun traffic on the real interface. Imagine you have some sort of tunnel working with a tun interface to a remote LAN, and on the same box you have regular internet streams (http, ftp, smtp etc...). Through the tunnel between the two LANs you have http, ftp, smtp traffic, but also maybe NetBT and a few MS streams. You naturaly would want to regulate the whole traffic (ie to/from Internet and to/from the remote LAN). But with AltQ you can't because you only will be able to create two different and unrelated queueing disciplines. For example with CBR you can't have a class associated with tun0 borrow some bandwidth from an inactive class associated with the physical interface (and vice-versa). The only solution to this problem, IMHO is to put the bandwidth management system just before/after the kernel IP input/output routine, just where IPFilter/IPFW is. IIRC this feature is marked in red in Darren Reed's (IPFilter author) TODO list. Too bad I haven't time to hack dummynet or something else into IPFilter ... :-( -- Rémi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message