[PATCH] 802.1p priority (fixed)

[Brooks Davis]

On Sat, Jan 22, 2005 at 10:50:18AM +0500, Boris Kovalenko wrote:
> Hello!
> 
> 	802.1p is just a 3 bits of 802.1Q header. Based on it Layer 2 
> 	devices may assign packets to different output queues (more simple, 802.1p 
> is QoS at Layer 2). So, You have right, this value differentiates packets 
> within a vlan and Layer 2 device may make a decision what packets should 
> be processed first. Of course, we may give the application the ability 
> to set this value itself, but what to do with old applications that have 
> no knowledge about this ability? Ok, You suppose to mark packets within 
> PF/IPFW. Yes, the idea is good too, but what to do on routers not 
> 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 
> application level information or override it. For example
> ipfw add 802.1p trust 6 on any to any ssh <-- this trust application 
> 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 
> 802.1p == 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 
> 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=0 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.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20050122/35427297/attachment.bin