WMM classification guideline for applications?

WMM classification guideline for applications?

[Kalle Valo]

Hello,

me and Patrik have been pondering what's the proper way for user space
applications to do packet classification to get the benefits from WMM.
VoIP application is a good example here.

For the time being we have identified three different methods:

1. SO_PRIORITY with values 0-7 (we used this in nokia n810)
2. SO_PRIORITY with values 256-263 (used by mac80211)
3. IPv4 DSCP field with values 0-7 (used by mac80211)

Method 1 is easy, applications need to just use setsockopt() and be
done with it. I don't know how widely supported values 0-7 are, but at
least they make sense. The problem is that priority is used only in
the first link, rest of the route is not able to benefit from the
classification.

Method 2 (priorities 256-263) doesn't sound very portable. I doubt if
any other stack or driver (even non-wifi ones) use these values.
Otherwise this is similar with Method 1.

Method 3 (IPv4 DSCP field) feels most portable to us, at least most,
if not all, wifi drivers should use it. And, in theory, the receiver
should also benefit from the classification, unless ISPs modify it of
course. But the standardisation for IPv4 QoS bits is a mess and I
don't really understand where the use of DSCP bits (as used in WMM
implementations) is specified. Also I was told that root privileges
are needed to set this and that's somewhat cumbersome from application
developer's point of view.

So what's the proper long term solution for this? All ideas are more
than welcome.

-- 
Kalle Valo

Re: WMM classification guideline for applications?

[David Acker]

Kalle Valo wrote:
> Hello,
> 
> me and Patrik have been pondering what's the proper way for user space
> applications to do packet classification to get the benefits from WMM.
> VoIP application is a good example here.
> 
> For the time being we have identified three different methods:
> 
> 1. SO_PRIORITY with values 0-7 (we used this in nokia n810)
> 2. SO_PRIORITY with values 256-263 (used by mac80211)
> 3. IPv4 DSCP field with values 0-7 (used by mac80211)
> 
> Method 1 is easy, applications need to just use setsockopt() and be
> done with it. I don't know how widely supported values 0-7 are, but at
> least they make sense. The problem is that priority is used only in
> the first link, rest of the route is not able to benefit from the
> classification.
> 
> Method 2 (priorities 256-263) doesn't sound very portable. I doubt if
> any other stack or driver (even non-wifi ones) use these values.
> Otherwise this is similar with Method 1.
> 
> Method 3 (IPv4 DSCP field) feels most portable to us, at least most,
> if not all, wifi drivers should use it. And, in theory, the receiver
> should also benefit from the classification, unless ISPs modify it of
> course. But the standardisation for IPv4 QoS bits is a mess and I
> don't really understand where the use of DSCP bits (as used in WMM
> implementations) is specified. Also I was told that root privileges
> are needed to set this and that's somewhat cumbersome from application
> developer's point of view.

What do think of also supporting a method 4, VLAN priority field (0-7)?
-ack

Re: WMM classification guideline for applications?

[Kalle Valo]

David Acker <dacker@roinet.com> writes:

> Kalle Valo wrote:
>> Hello,
>>
>> me and Patrik have been pondering what's the proper way for user space
>> applications to do packet classification to get the benefits from WMM.
>> VoIP application is a good example here.
>>
>> For the time being we have identified three different methods:
>>
>> 1. SO_PRIORITY with values 0-7 (we used this in nokia n810)
>> 2. SO_PRIORITY with values 256-263 (used by mac80211)
>> 3. IPv4 DSCP field with values 0-7 (used by mac80211)

[...]

> What do think of also supporting a method 4, VLAN priority field (0-7)?

Sorry, I haven't heard about this. I don't even know how applications
should set this. Can you show an example, please?

-- 
Kalle Valo

Re: WMM classification guideline for applications?

[David Acker]

Kalle Valo wrote:
> David Acker <dacker@roinet.com> writes:
>> What do think of also supporting a method 4, VLAN priority field (0-7)?
> 
> Sorry, I haven't heard about this. I don't even know how applications
> should set this. Can you show an example, please?

Sure.  A system could be setup with multiple VLANs available on its 
outgoing port.  Imagine eth0.1, eth0.2 and eth0.7.  Each one is a 
different VLAN with a different priority mapping setup.  The application 
can use the high priority VLAN which should then be reflected in the 
over the air packets using a high priority WMM queue.  If the driver 
implements the appropriate VLAN functionality it should be able to 
detect VLAN tagged packets and pick the appropriate WMM hardware queue. 
  I think a driver can use vlan_get_tag to get the Tag Control 
Information (TCI) field.  The TCI field contains a 3-bit Priority Code 
Point (PCP) field for 8 different priorities.

I am not an expert on how the kernel handles vlans, but it appears that 
the priority field's value is set by the user space VLAN creation tools 
through an ioctl with SET_VLAN_EGRESS_PRIORITY_CMD which calls 
vlan_dev_set_egress_priority to map an skb priority to a vlan priority.
vlan_dev_hard_header then uses this information to populate the vlan 
priority field based on the skb priority field.

In this case it would seem that skb priority and the vlan priority are 
both set and there may be a non-trivial mapping between the two. 
pkt_sched.h defines some skb priorities but also leaves many undefined. 
  The skb->priority is also larger then the vlan priority.  If both are 
set, which will take precedence?
-ack

Re: WMM classification guideline for applications?

[Greg Oliver]

On Fri, Dec 4, 2009 at 10:08 AM, David Acker <dacker@roinet.com> wrote:
> Kalle Valo wrote:
>>
>> David Acker <dacker@roinet.com> writes:
>>>
>>> What do think of also supporting a method 4, VLAN priority field (0-7)?
>>
>> Sorry, I haven't heard about this. I don't even know how applications
>> should set this. Can you show an example, please?
>
> Sure.  A system could be setup with multiple VLANs available on its outgoing
> port.  Imagine eth0.1, eth0.2 and eth0.7.  Each one is a different VLAN with
> a different priority mapping setup.  The application can use the high
> priority VLAN which should then be reflected in the over the air packets
> using a high priority WMM queue.  If the driver implements the appropriate
> VLAN functionality it should be able to detect VLAN tagged packets and pick
> the appropriate WMM hardware queue.  I think a driver can use vlan_get_tag
> to get the Tag Control Information (TCI) field.  The TCI field contains a
> 3-bit Priority Code Point (PCP) field for 8 different priorities.
>
> I am not an expert on how the kernel handles vlans, but it appears that the
> priority field's value is set by the user space VLAN creation tools through
> an ioctl with SET_VLAN_EGRESS_PRIORITY_CMD which calls
> vlan_dev_set_egress_priority to map an skb priority to a vlan priority.
> vlan_dev_hard_header then uses this information to populate the vlan
> priority field based on the skb priority field.
>
> In this case it would seem that skb priority and the vlan priority are both
> set and there may be a non-trivial mapping between the two. pkt_sched.h
> defines some skb priorities but also leaves many undefined.  The
> skb->priority is also larger then the vlan priority.  If both are set, which
> will take precedence?
> -ack

I do nto mean to be negative, but how can vlan based priority mapping
be anything but "going in reverse" by today's QoS standards?  The
whole point of packet marking is to alleviate the "this port is better
than that port", so traffic from any port can be made equal to that of
another..  Port (vlan/subnet/interface, etc) agnostic...  This would
seem like a regression to me...  All of the major router/switch
vendors provide mappings between these techniques already for this
reason.  Hopefully, they will not be needed much longer.

> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: WMM classification guideline for applications?

[Dan Williams]

On Fri, 2009-12-04 at 10:56 -0600, Greg Oliver wrote:
> On Fri, Dec 4, 2009 at 10:08 AM, David Acker <dacker@roinet.com> wrote:
> > Kalle Valo wrote:
> >>
> >> David Acker <dacker@roinet.com> writes:
> >>>
> >>> What do think of also supporting a method 4, VLAN priority field (0-7)?
> >>
> >> Sorry, I haven't heard about this. I don't even know how applications
> >> should set this. Can you show an example, please?
> >
> > Sure.  A system could be setup with multiple VLANs available on its outgoing
> > port.  Imagine eth0.1, eth0.2 and eth0.7.  Each one is a different VLAN with
> > a different priority mapping setup.  The application can use the high
> > priority VLAN which should then be reflected in the over the air packets
> > using a high priority WMM queue.  If the driver implements the appropriate
> > VLAN functionality it should be able to detect VLAN tagged packets and pick
> > the appropriate WMM hardware queue.  I think a driver can use vlan_get_tag
> > to get the Tag Control Information (TCI) field.  The TCI field contains a
> > 3-bit Priority Code Point (PCP) field for 8 different priorities.
> >
> > I am not an expert on how the kernel handles vlans, but it appears that the
> > priority field's value is set by the user space VLAN creation tools through
> > an ioctl with SET_VLAN_EGRESS_PRIORITY_CMD which calls
> > vlan_dev_set_egress_priority to map an skb priority to a vlan priority.
> > vlan_dev_hard_header then uses this information to populate the vlan
> > priority field based on the skb priority field.
> >
> > In this case it would seem that skb priority and the vlan priority are both
> > set and there may be a non-trivial mapping between the two. pkt_sched.h
> > defines some skb priorities but also leaves many undefined.  The
> > skb->priority is also larger then the vlan priority.  If both are set, which
> > will take precedence?
> > -ack
> 
> I do nto mean to be negative, but how can vlan based priority mapping
> be anything but "going in reverse" by today's QoS standards?  The
> whole point of packet marking is to alleviate the "this port is better
> than that port", so traffic from any port can be made equal to that of
> another..  Port (vlan/subnet/interface, etc) agnostic...  This would
> seem like a regression to me...  All of the major router/switch
> vendors provide mappings between these techniques already for this
> reason.  Hopefully, they will not be needed much longer.

Also, I think that unless it's a simple as a setsockopt() or some
one-call method like that, app writers aren't really going to use it.
For something as conceptually simple as QoS (even if the implementation
is complex), as an app writer I'd want to say "this packet is priority
3" and not "this packet is priority 4, so I need to find the
corresponding VLAN, and if that's not set up for me already then fail".

Dan

Re: WMM classification guideline for applications?

[David Acker]

Dan Williams wrote:
> On Fri, 2009-12-04 at 10:56 -0600, Greg Oliver wrote:
>> On Fri, Dec 4, 2009 at 10:08 AM, David Acker <dacker@roinet.com> wrote:
>>> Kalle Valo wrote:
>>>> David Acker <dacker@roinet.com> writes:
>>>>> What do think of also supporting a method 4, VLAN priority field (0-7)?
>>>> Sorry, I haven't heard about this. I don't even know how applications
>>>> should set this. Can you show an example, please?
>>> Sure.  A system could be setup with multiple VLANs available on its outgoing
>>> port.  Imagine eth0.1, eth0.2 and eth0.7.  Each one is a different VLAN with
>>> a different priority mapping setup.  The application can use the high
>>> priority VLAN which should then be reflected in the over the air packets
>>> using a high priority WMM queue.  If the driver implements the appropriate
>>> VLAN functionality it should be able to detect VLAN tagged packets and pick
>>> the appropriate WMM hardware queue.  I think a driver can use vlan_get_tag
>>> to get the Tag Control Information (TCI) field.  The TCI field contains a
>>> 3-bit Priority Code Point (PCP) field for 8 different priorities.
>>>
>>> I am not an expert on how the kernel handles vlans, but it appears that the
>>> priority field's value is set by the user space VLAN creation tools through
>>> an ioctl with SET_VLAN_EGRESS_PRIORITY_CMD which calls
>>> vlan_dev_set_egress_priority to map an skb priority to a vlan priority.
>>> vlan_dev_hard_header then uses this information to populate the vlan
>>> priority field based on the skb priority field.
>>>
>>> In this case it would seem that skb priority and the vlan priority are both
>>> set and there may be a non-trivial mapping between the two. pkt_sched.h
>>> defines some skb priorities but also leaves many undefined.  The
>>> skb->priority is also larger then the vlan priority.  If both are set, which
>>> will take precedence?
>>> -ack
>> I do nto mean to be negative, but how can vlan based priority mapping
>> be anything but "going in reverse" by today's QoS standards?  The
>> whole point of packet marking is to alleviate the "this port is better
>> than that port", so traffic from any port can be made equal to that of
>> another..  Port (vlan/subnet/interface, etc) agnostic...  This would
>> seem like a regression to me...  All of the major router/switch
>> vendors provide mappings between these techniques already for this
>> reason.  Hopefully, they will not be needed much longer.
> 
> Also, I think that unless it's a simple as a setsockopt() or some
> one-call method like that, app writers aren't really going to use it.
> For something as conceptually simple as QoS (even if the implementation
> is complex), as an app writer I'd want to say "this packet is priority
> 3" and not "this packet is priority 4, so I need to find the
> corresponding VLAN, and if that's not set up for me already then fail".

On the other hand, an administrator could create a high priority VLAN/IP 
subnet and setup the mapping so that the default skb priority goes to a 
high priority vlan.  The applications using this don't have to change at 
all.

Minimally, I think that Linux wireless needs to define what priority 
related fields it uses to drive WMM.  It is fine to ignore the VLAN 
priority as long as it is documented.  Going with the skb priority 
sounds like a good plan since it is used to drive the VLAN priority anyway.

Going with IPv4 DSCP may be a bit problematic.  See 
http://marc.info/?l=linux-netdev&m=125875775229644&w=2 and 
http://sourceware.org/bugzilla/show_bug.cgi?id=10789 .
-ack

Re: WMM classification guideline for applications?

[Kalle Valo]

Dan Williams <dcbw@redhat.com> writes:

> On Fri, 2009-12-04 at 10:56 -0600, Greg Oliver wrote:
>
>> I do nto mean to be negative, but how can vlan based priority mapping
>> be anything but "going in reverse" by today's QoS standards?  The
>> whole point of packet marking is to alleviate the "this port is better
>> than that port", so traffic from any port can be made equal to that of
>> another..  Port (vlan/subnet/interface, etc) agnostic...  This would
>> seem like a regression to me...  All of the major router/switch
>> vendors provide mappings between these techniques already for this
>> reason.  Hopefully, they will not be needed much longer.
>
> Also, I think that unless it's a simple as a setsockopt() or some
> one-call method like that, app writers aren't really going to use it.

Exactly. It needs to be so simple that application developers can just
copy paste it to their code without a second thought. Remember we (as
in community) want even proprietary applications like skype to support
this.

And this method, whatever it will be, should be universal so that it
can be used with different technologies: Wi-Fi, Wimax, cellular data
and whatnot. Otherwise it doesn't make any sense, usually applications
don't care over which technology the packets are transmitted.

-- 
Kalle Valo

Re: WMM classification guideline for applications?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

On Fri, 2009-12-04 at 11:08 -0500, David Acker wrote:

> I am not an expert on how the kernel handles vlans, but it appears that 
> the priority field's value is set by the user space VLAN creation tools 
> through an ioctl with SET_VLAN_EGRESS_PRIORITY_CMD which calls 
> vlan_dev_set_egress_priority to map an skb priority to a vlan priority.
> vlan_dev_hard_header then uses this information to populate the vlan 
> priority field based on the skb priority field.
> 
> In this case it would seem that skb priority and the vlan priority are 
> both set and there may be a non-trivial mapping between the two. 

But doesn't that also mean that mac80211 can happily ignore the VLAN
priority in the packet, because the vlan code will have propagated it to
the skb->priority, if the administrator wishes to use it?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: WMM classification guideline for applications?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]

On Fri, 2009-12-04 at 16:02 +0200, Kalle Valo wrote:

> Method 3 (IPv4 DSCP field) feels most portable to us, at least most,
> if not all, wifi drivers should use it. And, in theory, the receiver
> should also benefit from the classification, unless ISPs modify it of
> course. But the standardisation for IPv4 QoS bits is a mess and I
> don't really understand where the use of DSCP bits (as used in WMM
> implementations) is specified. 

http://tools.ietf.org/rfc/rfc2474.txt ?

> Also I was told that root privileges
> are needed to set this and that's somewhat cumbersome from application
> developer's point of view.

I don't see that IP_TOS, which will end up setting IP TOS/DSCP, requires
any elevated privileges:

        case IP_TOS:    /* This sets both TOS and Precedence */
                if (sk->sk_type == SOCK_STREAM) {
                        val &= ~3;
                        val |= inet->tos & 3; 
                }
                if (inet->tos != val) {
                        inet->tos = val;
                        sk->sk_priority = rt_tos2priority(val);
                        sk_dst_reset(sk);
                }
                break;

whereas, for instance:

        case IP_IPSEC_POLICY:
        case IP_XFRM_POLICY:
                err = -EPERM;
                if (!capable(CAP_NET_ADMIN))
                        break;

In any case, I think this topic would benefit of cross-posting to
netdev :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: WMM classification guideline for applications?

[David Acker]

Johannes Berg wrote:
> On Fri, 2009-12-04 at 11:08 -0500, David Acker wrote:
> 
>> I am not an expert on how the kernel handles vlans, but it appears that 
>> the priority field's value is set by the user space VLAN creation tools 
>> through an ioctl with SET_VLAN_EGRESS_PRIORITY_CMD which calls 
>> vlan_dev_set_egress_priority to map an skb priority to a vlan priority.
>> vlan_dev_hard_header then uses this information to populate the vlan 
>> priority field based on the skb priority field.
>>
>> In this case it would seem that skb priority and the vlan priority are 
>> both set and there may be a non-trivial mapping between the two. 
> 
> But doesn't that also mean that mac80211 can happily ignore the VLAN
> priority in the packet, because the vlan code will have propagated it to
> the skb->priority, if the administrator wishes to use it?

You are correct on rx.  The tricky part is the non-trivial mapping on 
tx.  If mac80211 only looks at the skb->priority and assumes priority 0 
means best effort, the code could be missing that skb->priority 0 maps 
to vlan priority 7.  If we define that mac80211 only looks at 
skb->priority, perhaps we should allow user space control of the mapping 
of the skb->priority to WMM priority queue.  This could be similar to 
the mapping capabilities in the VLAN code.  That way, an admin can make 
sure that the skb priority is mapped to both an appropriate vlan 
priority and an appropriate WMM priority queue.
-ack


__________ Information from ESET Smart Security, version of virus signature database 4663 (20091205) __________

The message was checked by ESET Smart Security.

http://www.eset.com

Re: WMM classification guideline for applications?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]

On Sun, 2009-12-06 at 13:10 -0500, David Acker wrote:
> Johannes Berg wrote:
> > On Fri, 2009-12-04 at 11:08 -0500, David Acker wrote:
> > 
> >> I am not an expert on how the kernel handles vlans, but it appears that 
> >> the priority field's value is set by the user space VLAN creation tools 
> >> through an ioctl with SET_VLAN_EGRESS_PRIORITY_CMD which calls 
> >> vlan_dev_set_egress_priority to map an skb priority to a vlan priority.
> >> vlan_dev_hard_header then uses this information to populate the vlan 
> >> priority field based on the skb priority field.
> >>
> >> In this case it would seem that skb priority and the vlan priority are 
> >> both set and there may be a non-trivial mapping between the two. 
> > 
> > But doesn't that also mean that mac80211 can happily ignore the VLAN
> > priority in the packet, because the vlan code will have propagated it to
> > the skb->priority, if the administrator wishes to use it?
> 
> You are correct on rx.

I don't see how RX matters at all, to mac80211?

>   The tricky part is the non-trivial mapping on 
> tx.  If mac80211 only looks at the skb->priority and assumes priority 0 
> means best effort, the code could be missing that skb->priority 0 maps 
> to vlan priority 7.  If we define that mac80211 only looks at 
> skb->priority, perhaps we should allow user space control of the mapping 
> of the skb->priority to WMM priority queue.  This could be similar to 
> the mapping capabilities in the VLAN code.  That way, an admin can make 
> sure that the skb priority is mapped to both an appropriate vlan 
> priority and an appropriate WMM priority queue.

I don't understand. If I TX a packet, on a specific VLAN, then it'll go
through the VLAN code first, get 802.1q tags and then be passed to
mac80211, which ought be be fine with just looking at the priority value
the packet now got.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: WMM classification guideline for applications?

[David Acker]

Johannes Berg wrote:
> On Sun, 2009-12-06 at 13:10 -0500, David Acker wrote:
>> Johannes Berg wrote:
>>> On Fri, 2009-12-04 at 11:08 -0500, David Acker wrote:
>>>
>>>> I am not an expert on how the kernel handles vlans, but it appears that 
>>>> the priority field's value is set by the user space VLAN creation tools 
>>>> through an ioctl with SET_VLAN_EGRESS_PRIORITY_CMD which calls 
>>>> vlan_dev_set_egress_priority to map an skb priority to a vlan priority.
>>>> vlan_dev_hard_header then uses this information to populate the vlan 
>>>> priority field based on the skb priority field.
>>>>
>>>> In this case it would seem that skb priority and the vlan priority are 
>>>> both set and there may be a non-trivial mapping between the two. 
>>> But doesn't that also mean that mac80211 can happily ignore the VLAN
>>> priority in the packet, because the vlan code will have propagated it to
>>> the skb->priority, if the administrator wishes to use it?
>> You are correct on rx.
> 
> I don't see how RX matters at all, to mac80211?
When a packet is received on a higher priority WMM queue, should it 
reflect that in skb->priority?

> 
>>   The tricky part is the non-trivial mapping on 
>> tx.  If mac80211 only looks at the skb->priority and assumes priority 0 
>> means best effort, the code could be missing that skb->priority 0 maps 
>> to vlan priority 7.  If we define that mac80211 only looks at 
>> skb->priority, perhaps we should allow user space control of the mapping 
>> of the skb->priority to WMM priority queue.  This could be similar to 
>> the mapping capabilities in the VLAN code.  That way, an admin can make 
>> sure that the skb priority is mapped to both an appropriate vlan 
>> priority and an appropriate WMM priority queue.
> 
> I don't understand. If I TX a packet, on a specific VLAN, then it'll go
> through the VLAN code first, get 802.1q tags and then be passed to
> mac80211, which ought be be fine with just looking at the priority value
> the packet now got.

The packet will get tags which will contain the vlan priority mapped 
from the original skb->priority.  What if the administrator wanted all 
applications that used a specific VLAN to have high priority.  Without 
having to change the applications, he could make the mapping of skb 
priority 0 to go a high priority VLAN.  It would be nice if he could 
also make skb->priority 0 go to a high priority WMM queue.  It is fine 
to base every thing on the skb priority but it would be nice if the 
mapping of skb priority to WMM queue was not static.  It should have a 
user space API that is similar in functionality to the VLAN priority API.

As an example, I have a system where a wireless router has multiple 
SSIDs.  One SSID is for guests and has little or no security and is on 
VLAN 1 with a VLAN priority of 0.  Another SSID is for system 
configuration and has high security (802.11i) and is on VLAN 2 with a 
VLAN priority of 7.  The VLAN tagging is handled by the router; clients 
send normal frames.  Their applications do not require any changes.  The 
router will give higher priority to the system configuration VLAN during 
any queuing.  When the packets are sent, I have code (in madwifi in this 
example) to put the packets with VLAN priority 0 in the best effort 
queue while packets in vlan priority 7 go into the voice queue.  This 
code also sets the skb->priority field based on the VLAN priority.  This 
allows the queuing of the packet to the wifi0 device to reflect the 
appropriate ordering.  The router supports meshing such that the WMM 
queues are used for packets between the routers.  In this manner, the 
QoS required for the higher priority VLAN is reflected through the whole 
network, including the eventual wired destination.

To support this in mac80211, it would be nice to specify the mapping of 
skb->priority to WMM queue on a per SSID basis.  This would allow QoS to 
be application driven or SSID driven.
-ack


__________ Information from ESET Smart Security, version of virus signature database 4665 (20091206) __________

The message was checked by ESET Smart Security.

http://www.eset.com

Re: WMM classification guideline for applications?

[Kalle Valo]

David Acker <dacker@roinet.com> writes:

> Going with IPv4 DSCP may be a bit problematic.  See
> http://marc.info/?l=linux-netdev&m=125875775229644&w=2 and
> http://sourceware.org/bugzilla/show_bug.cgi?id=10789 .

Thanks, these are good links. 

I don't see this as an obstacle, though. If we have issues, we'll fix
them. This QoS support is such a mess that if we want to do this
properly, there is no way to avoid some pain.

-- 
Kalle Valo

Re: WMM classification guideline for applications?

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Fri, 2009-12-04 at 16:02 +0200, Kalle Valo wrote:
>
>> Method 3 (IPv4 DSCP field) feels most portable to us, at least most,
>> if not all, wifi drivers should use it. And, in theory, the receiver
>> should also benefit from the classification, unless ISPs modify it of
>> course. But the standardisation for IPv4 QoS bits is a mess and I
>> don't really understand where the use of DSCP bits (as used in WMM
>> implementations) is specified. 
>
> http://tools.ietf.org/rfc/rfc2474.txt ?

This wasn't clear to me, so I investigated this a bit. This is what I
found:

The user priorities (0-7) are defined in IEEE 802.1D-2004 Annex G. I
believe this the output from task group 802.1p. The mapping from user
priorities (UP) to 802.11 queues is both in the WMM spec and in IEEE
802.11-2007 Table 9-1.

Like you said, DSCP is defined in RFC 2474 "Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers". But the definition is IMHO very vague:

4.3  Summary

   "This document defines codepoints 'xxx000' as the Class Selector
   codepoints, where PHBs selected by these codepoints MUST meet the
   Class Selector PHB Requirements described in Sec. 4.2.2.2. This is
   done to preserve a useful level of backward compatibility with
   current uses of the IP Precedence field in the Internet without
   unduly limiting future flexibility. In addition, codepoint '000000'
   is used as the Default PHB value for the Internet and, as such, is
   not configurable. The remaining seven non-zero Class Selector
   codepoints are configurable only to the extent that they map to
   PHBs that meet the requirements in Sec. 4.2.2.2."


4.2.2.2  The Class Selector PHB Requirements

   "We refer to a Class Selector Codepoint with a larger numerical
   value than another Class Selector Codepoint as having a higher
   relative order while a Class Selector Codepoint with a smaller
   numerical value than another Class Selector Codepoint is said to
   have a lower relative order. The set of PHBs mapped to by the eight
   Class Selector Codepoints MUST yield at least two independently
   forwarded classes of traffic, and PHBs selected by a Class Selector
   Codepoint SHOULD give packets a probability of timely forwarding
   that is not lower than that given to packets marked with a Class
   Selector codepoint of lower relative order, under reasonable
   operating conditions and traffic loads."

>From the text above you can, somehow, make the assumption that it's ok
to use priorities 0-7 in DSCP bits 0-3. There's also a requirement for
backwards support of IP Precedence bit:

   "PHBs selected by codepoints '11x000' MUST give packets a
   preferential forwarding treatment by comparison to the PHB selected
   by codepoint '000000' to preserve the common usage of IP Precedence
   values '110' and '111' for routing traffic."

Because '110' is mapped to UP 6 and '111' is UP 7, that requirement is
also fulfilled.

But I didn't find anywhere explicit mappings between DSCP and 802.1d
priorities. Being an 802 standard 802.1d only talks about MAC level,
just as it should. Also from RFCs I didn't find anything more concrete
than above.

So from this I guess I can conclude that it is acceptable to use
802.1d user priorities in DSCP. At least I hope so :)

>> Also I was told that root privileges
>> are needed to set this and that's somewhat cumbersome from application
>> developer's point of view.
>
> I don't see that IP_TOS, which will end up setting IP TOS/DSCP, requires
> any elevated privileges:

[...]

I tested with a small python script and you are correct, as usual. No
extra priviliges were needed.

> In any case, I think this topic would benefit of cross-posting to
> netdev :)

I will definitely do that. I just wanted to hear opinions from the
wireless crowd first.

I'll create a wiki page summarising this and then ask from netdev.

-- 
Kalle Valo