From owner-freebsd-net@FreeBSD.ORG Sat Jan 22 20:24:21 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81AA116A4CE for ; Sat, 22 Jan 2005 20:24:21 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4204343D46 for ; Sat, 22 Jan 2005 20:24:21 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j0MKOgeY009129; Sat, 22 Jan 2005 12:24:42 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j0MKOdEd009126; Sat, 22 Jan 2005 12:24:39 -0800 Date: Sat, 22 Jan 2005 12:24:39 -0800 From: Brooks Davis To: Boris Kovalenko Message-ID: <20050122202439.GA4466@odin.ac.hmc.edu> References: <41F1E99A.5070001@ntmk.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <41F1E99A.5070001@ntmk.ru> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-net@freebsd.org Subject: Re: [PATCH] 802.1p priority (fixed) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2005 20:24:21 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 22, 2005 at 10:50:18AM +0500, Boris Kovalenko wrote: > Hello! >=20 > 802.1p is just a 3 bits of 802.1Q header. Based on it Layer 2=20 > devices may assign packets to different output queues (more simple, 802.= 1p=20 > is QoS at Layer 2). So, You have right, this value differentiates packets= =20 > within a vlan and Layer 2 device may make a decision what packets should= =20 > be processed first. Of course, we may give the application the ability=20 > to set this value itself, but what to do with old applications that have= =20 > no knowledge about this ability? Ok, You suppose to mark packets within= =20 > PF/IPFW. Yes, the idea is good too, but what to do on routers not=20 > running any firewall software? So, may be right way will be: I'm slightly concerned about the old application issue, but more about binary-only code then applications with source. I don't think the issue of forcing people to run a firewall is significant. These days you can just load one since PFIL_HOOK are non-optional. There's also the fact that this is a feature that is not useful unless you understand the implications (including the fact that you can't trust the values unless you trust the wire and those on it.) Priorities have the potential to be a powerful tool, but I think there are a lot of subtleties when you start using them on end-hosts. > 1. Mark 802.1p at application level > 2. Mark 802.1p at PF/IPFW level. But we shold foresee a keyword to trust= =20 > application level information or override it. For example > ipfw add 802.1p trust 6 on any to any ssh <-- this trust application=20 > level information and set 802.1p to 6 if it is omitted > ipfw add 802.1p override 6 on any to any ssh <-- this silently set=20 > 802.1p =3D=3D 6, regardless of application I'm not sure why you need trust and override. It seems like you only need the ability to set or remove values as well as acting on already attached tags (which we're going to need to carry around as m_tags so we can filter on and modify them in conjunction with layer 3 information). > 3. Mark 802.1p at vlan drivers like 2 > ifconfig vlan0 > vlan: 100 802.1p: 6 CFI: 0 mode: trust vlandev: bge0 > Here we are trusting received from low level information and set 6 if it= =20 > is omitted > ifconfig vlan0 > vlan: 100 802.1p: 6 CFI: 0 mode: override vlandev: bge0 > Here we silently set 6. If you're not going to do separate interfaces per priority (or perhaps set of priorities[0]) I'm not sure what the point of having the interface do anything is. Filtering is the job of the firewall so I'm not convinced we should be doing it in the vlan device. There's also the complication that we need to handle the vlan=3D0 case which shouldn't be treated as a vlan at all and should be decapsulated in the actual device without a trip through the vlan code. My suspicion is that we need to rethink the current separation of ether and vlan code. Making vlans less optional and doing more of the handling in ether_input and ether_output might be a good thing. -- Brooks [0] What I've read says that many switches group sets of priority values together reducing the set of valid values. --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB8raGXY6L6fI4GtQRAlHbAKCz3v6ZrwDPi7I77zZZZctf+fDCogCg51Qv QnUXmKVtm0J4N2diRJvp3ow= =8/hY -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6--