From owner-freebsd-pf@FreeBSD.ORG Thu Dec 23 09:03:18 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99F52106566B for ; Thu, 23 Dec 2010 09:03:18 +0000 (UTC) (envelope-from Aleksej.Spenst@harman.com) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by mx1.freebsd.org (Postfix) with SMTP id E321E8FC1A for ; Thu, 23 Dec 2010 09:03:17 +0000 (UTC) Received: from source ([194.121.90.173]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTRMQVfwTMtH+aspjH2bTSYPSHkIhNc+n@postini.com; Thu, 23 Dec 2010 01:03:18 PST Received: from HIKAWSEX01.ad.harman.com ([fe80::28ec:7810:cfab:2739]) by HIKAWSEX03.ad.harman.com ([172.16.1.217]) with mapi; Thu, 23 Dec 2010 10:03:15 +0100 From: "Spenst, Aleksej" To: "'Ricky Charlet'" , "'freebsd-pf@freebsd.org'" Date: Thu, 23 Dec 2010 10:03:15 +0100 Thread-Topic: why ALTQ must be supported by interface drivers? Thread-Index: Acuhz70V44smhZJVTimJ0E+cLgBkGAAJwq/AACD4qnA= Message-ID: <20290C577F743240B5256C89EFA753810CAC5EC007@HIKAWSEX01.ad.harman.com> References: <20290C577F743240B5256C89EFA753810CAC5EC003@HIKAWSEX01.ad.harman.com> <32AB5C9615CC494997D9ABB1DB12783C024C6FC1BC@SJ-EXCH-1.adaranet.com> In-Reply-To: <32AB5C9615CC494997D9ABB1DB12783C024C6FC1BC@SJ-EXCH-1.adaranet.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: AW: why ALTQ must be supported by interface drivers? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 09:03:19 -0000 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" >=