Date: Thu, 23 Dec 2010 10:03:15 +0100 From: "Spenst, Aleksej" <Aleksej.Spenst@harman.com> To: "'Ricky Charlet'" <RCharlet@adaranet.com>, "'freebsd-pf@freebsd.org'" <freebsd-pf@freebsd.org> Subject: AW: why ALTQ must be supported by interface drivers? Message-ID: <20290C577F743240B5256C89EFA753810CAC5EC007@HIKAWSEX01.ad.harman.com> In-Reply-To: <32AB5C9615CC494997D9ABB1DB12783C024C6FC1BC@SJ-EXCH-1.adaranet.com> References: <20290C577F743240B5256C89EFA753810CAC5EC003@HIKAWSEX01.ad.harman.com> <32AB5C9615CC494997D9ABB1DB12783C024C6FC1BC@SJ-EXCH-1.adaranet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Ricky, Thanks for your explanations.=20 >If, in-fact, a driver happens to=20 >implement another queue underneath the AltQ queue (sometimes=20 >happens in sophisticated hardware) then this 'lower' queue=20 >will probably be a FIFO queue and may wind up destroying the=20 >value of AltQ. If the driver supports only one FIFO queue, I don't think it can destroy AL= TQ functionality, since prioritization of traffic is done at layer 3 and th= is FIFO queue at layer 2 can be used to send packets in the order according= to classification performed at layer 3. However, if the driver supports it= s own queuing mechanism I see that there can be problems. I don't think tha= t pf has to be aware of layer 2 queuing mechanism to make any kind of mappi= ng between two queuing systems at layers 2 and 3. So, I suppose, either pf = disables the queuing mechanism at layer 2 or pf makes nothing (but in this = case one wouldn't need the driver to support pf). So, I'm still not sure wh= y pf needs the drivers to support ALTQ. >In conclusion, AltQ enforcement must be implemented at=20 >the lowest layer, and AltQ classification should maintain=20 >ability to examine low level headers even though it is much=20 >more common to examine layer3 /layer4 headers. Ok, this would answer my question, but what kind of layer 2 classification = is supported by pf? I don't remember any pf rules that can set layer 2 tags= or filter all packets based on layer 2 information. Thanks, Aleksej. >-----Urspr=FCngliche Nachricht----- >Von: Ricky Charlet [mailto:RCharlet@adaranet.com]=20 >Gesendet: Mittwoch, 22. Dezember 2010 17:55 >An: Spenst, Aleksej; 'freebsd-pf@freebsd.org' >Betreff: RE: why ALTQ must be supported by interface drivers? > >Hi Aleksej, > > I happen to have recently been 'playing' with altq and=20 >trying to (successfully eventually) get to work well in the=20 >100Mb utilization range. > > So you need to think of it like this, AltQ is=20 >replacing a current queueing system... that of the driver.=20 >Each driver has a simple FIFO queue. AltQ is just a more=20 >sophisticated queue for the driver to use when sending out=20 >packets (enforcement). If, in-fact, a driver happens to=20 >implement another queue underneath the AltQ queue (sometimes=20 >happens in sophisticated hardware) then this 'lower' queue=20 >will probably be a FIFO queue and may wind up destroying the=20 >value of AltQ. > > Now a piece of that added sophistication is=20 >classification. Site administrators set policy on which=20 >packets are more or less preferential to drop during=20 >congestion. AltQ's classification is implemented via the=20 >packet-filters. > > A very common use case for classification is to=20 >distinguish traffic based on layer3 and layer4 (IP and=20 >TCP/UDP/ICMP/SCTP...) headers. However this is not the only=20 >use case and classification based on layer2 headers should=20 >continue to be supported for those few sites that wish it. > > In conclusion, AltQ enforcement must be implemented at=20 >the lowest layer, and AltQ classification should maintain=20 >ability to examine low level headers even though it is much=20 >more common to examine layer3 /layer4 headers. > > > So much for philosophy. About compiling, yes you=20 >understood quite correctly. I have found these web sites to=20 >have helpful AltQ info (in no particular 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-=20 >> 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=20 >level or at=20 >> the driver level? >> >> I would think that all queuing functionality is probabliy working at=20 >> the IP level and should not depend on underlying interfaces. Is that=20 >> correct? If this is true, I don't understand why ALTQ must be=20 >> supported by interface drivers? If I understand it=20 >correctly: (1) the=20 >> driver has to support ALTQ. (2) the driver has to be compiled as=20 >> 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?20290C577F743240B5256C89EFA753810CAC5EC007>