Hi Ricky, Thanks for your explanations.
>If, in-fact, a driver happens to >implement another queue underneath the AltQ queue (sometimes >happens in sophisticated hardware) then this 'lower' queue >will probably be a FIFO queue and may wind up destroying the >value of AltQ. If the driver supports only one FIFO queue, I don't think it can destroy ALTQ functionality, since prioritization of traffic is done at layer 3 and this 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 its own queuing mechanism I see that there can be problems. I don't think that pf has to be aware of layer 2 queuing mechanism to make any kind of mapping 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 why pf needs the drivers to support ALTQ. >In conclusion, AltQ enforcement must be implemented at >the lowest layer, and AltQ classification should maintain >ability to examine low level headers even though it is much >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üngliche Nachricht----- >Von: Ricky Charlet [mailto:[email protected]] >Gesendet: Mittwoch, 22. Dezember 2010 17:55 >An: Spenst, Aleksej; '[email protected]' >Betreff: RE: why ALTQ must be supported by interface drivers? > >Hi Aleksej, > > I happen to have recently been 'playing' with altq and >trying to (successfully eventually) get to work well in the >100Mb utilization range. > > So you need to think of it like this, AltQ is >replacing a current queueing 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 another queue underneath the AltQ queue (sometimes >happens in sophisticated hardware) 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 administrators set policy on which >packets are more or less preferential to drop 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 should >continue to be supported for those few sites that wish it. > > In conclusion, AltQ enforcement must be implemented at >the lowest layer, and AltQ classification should maintain >ability to examine low level headers even though it is much >more common to examine layer3 /layer4 headers. > > > So much for philosophy. About compiling, yes you >understood quite correctly. I have found these web sites to >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: [email protected] [mailto:owner-freebsd- >> [email protected]] On Behalf Of Spenst, Aleksej >> Sent: Wednesday, December 22, 2010 4:00 AM >> To: '[email protected]' >> 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. >> >> >> >> >> _______________________________________________ >> [email protected] mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-pf >> To unsubscribe, send any mail to "[email protected]" >_______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[email protected]"
