Date: Tue, 1 May 2001 23:56:02 +0200 From: =?iso-8859-1?Q?R=E9mi_Guyomarch?= <rguyom@pobox.com> To: Gunther Schadow <gunther@aurora.regenstrief.org> 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> In-Reply-To: <3AEF0E6A.2E9B34A0@aurora.regenstrief.org>; from gunther@aurora.regenstrief.org on Tue, May 01, 2001 at 07:28:42PM %2B0000 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010501235602.B30269>