Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Dec 2010 08:54:55 -0800
From:      "Ricky  Charlet" <RCharlet@adaranet.com>
To:        "'Spenst, Aleksej'" <Aleksej.Spenst@harman.com>, "'freebsd-pf@freebsd.org'" <freebsd-pf@freebsd.org>
Subject:   RE: why ALTQ must be supported by interface drivers?
Message-ID:  <32AB5C9615CC494997D9ABB1DB12783C024C6FC1BC@SJ-EXCH-1.adaranet.com>
In-Reply-To: <20290C577F743240B5256C89EFA753810CAC5EC003@HIKAWSEX01.ad.harman.com>
References:  <20290C577F743240B5256C89EFA753810CAC5EC003@HIKAWSEX01.ad.harman.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Aleksej,

        I happen to have recently been 'playing' with altq and trying to (s=
uccessfully eventually) get to work well in the 100Mb utilization range.

        So you need to think of it like this, AltQ is replacing a current q=
ueueing system... that of the driver. Each driver has a simple FIFO queue. =
AltQ is just a more sophisticated queue for the driver to use when sending =
out packets (enforcement). If, in-fact, a driver happens to implement anoth=
er queue underneath the AltQ queue (sometimes happens in sophisticated hard=
ware) then this 'lower' queue will probably be a FIFO queue and may wind up=
 destroying the value of AltQ.

        Now a piece of that added sophistication is classification. Site ad=
ministrators set policy on which packets are more or less preferential to d=
rop during congestion. AltQ's classification is implemented via the packet-=
filters.

        A very common use case for classification is to distinguish traffic=
 based on layer3 and layer4 (IP and TCP/UDP/ICMP/SCTP...) headers. However =
this is not the only use case and classification based on layer2 headers sh=
ould continue to be supported for those few sites that wish it.

        In conclusion, AltQ enforcement must be implemented at the lowest l=
ayer, and AltQ classification should maintain ability to examine low level =
headers even though it is much more common to examine layer3 /layer4 header=
s.


        So much for philosophy. About compiling, yes you understood quite c=
orrectly. I have found these web sites to have helpful AltQ info (in no par=
ticular order):

http://www.sonycsl.co.jp/~kjc/software/altq-new-design.txt
http://www.sonycsl.co.jp/person/kjc/software.html#ALTQ
http://www.sonycsl.co.jp/person/kjc/software/TIPS.txt
http://www.openbsd.org/faq/pf/index.html
http://openbsd.org/faq/pf/queueing.html
http://loquefaltaba.com/documentacion/pf/en/altqintro.html
http://system-tribudi.blogspot.com/2006/08/pf-hfsc-part-i.html
http://www.probsd.net/pf/index.php/Hednod%27s_HFSC_explained
http://www.icir.org/floyd/cbq.html



---
Ricky Charlet





> -----Original Message-----
> From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-
> pf@freebsd.org] On Behalf Of Spenst, Aleksej
> Sent: Wednesday, December 22, 2010 4:00 AM
> To: 'freebsd-pf@freebsd.org'
> Subject: why ALTQ must be supported by interface drivers?
>
> Hi All,
>
> at what network level is ALTQ (QoS) implemented? At the IP level or at
> the driver level?
>
> I would think that all queuing functionality is probabliy working at
> the IP level and should not depend on underlying interfaces. Is that
> correct? If this is true, I don't understand why ALTQ must be supported
> by interface drivers? If I understand it correctly: (1) the driver has
> to support ALTQ. (2) the driver has to be compiled as ALTQ-aware with
> some special flags.
>
> Thanks,
> Aleksej.
>
>
>
>
> _______________________________________________
> freebsd-pf@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32AB5C9615CC494997D9ABB1DB12783C024C6FC1BC>