From: Kalle Valo <kalle.valo@iki.fi>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org, patrik.flykt@nokia.com
Subject: Re: WMM classification guideline for applications?
Date: Mon, 07 Dec 2009 17:50:33 +0200 [thread overview]
Message-ID: <87ein64wc6.fsf@purkki.valot.fi> (raw)
In-Reply-To: <1260097037.3461.10.camel@johannes.local> (Johannes Berg's message of "Sun\, 06 Dec 2009 11\:57\:17 +0100")
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
prev parent reply other threads:[~2009-12-07 15:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-04 14:02 WMM classification guideline for applications? Kalle Valo
2009-12-04 15:14 ` David Acker
2009-12-04 15:24 ` Kalle Valo
2009-12-04 16:08 ` David Acker
2009-12-04 16:56 ` Greg Oliver
2009-12-04 19:15 ` Dan Williams
2009-12-04 20:01 ` David Acker
2009-12-07 15:11 ` Kalle Valo
2009-12-04 21:01 ` Kalle Valo
2009-12-06 10:46 ` Johannes Berg
2009-12-06 18:10 ` David Acker
2009-12-06 18:32 ` Johannes Berg
2009-12-07 1:34 ` David Acker
2009-12-06 10:57 ` Johannes Berg
2009-12-07 15:50 ` Kalle Valo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ein64wc6.fsf@purkki.valot.fi \
--to=kalle.valo@iki.fi \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=patrik.flykt@nokia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).