linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* QoS and DSCP
@ 2008-08-19  8:46 Daniel Wagner
  2008-08-19  9:04 ` Johannes Berg
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Wagner @ 2008-08-19  8:46 UTC (permalink / raw)
  To: linux-wireless

Hi,

I was playing a bit with DSCP and my wireless setup. I don't know what 
the expected result should be there I'd like to ask you here what
is the expected result.

Server <---(ethernet)--> d-link AP <---(wireless)---> Desktop
192.168.100.1                                         192.168.202.198

On the server I have an icecast stream running on port 8000.

server# iptables -t mangle -A OUTPUT -p tcp --sport 8000 -j DSCP --set-dscp-class EF

The packets send from the AP to the desktop have the QoS Control Field Priority set
to 5:

Frame 13 (1622 bytes on wire, 1622 bytes captured)
PPI version 0, 84 bytes
IEEE 802.11 QoS Data, Flags: ......F.C
    Type/Subtype: QoS Data (0x28)
    Frame Control: 0x0288 (Normal)
    Duration: 48
    Destination address: IntelCor_9e:db:5d (00:1d:e0:9e:db:5d)
    BSS Id: D-Link_f0:b1:3c (00:1b:11:f0:b1:3c)
    Source address: D-Link_f0:b1:3c (00:1b:11:f0:b1:3c)
    Fragment number: 0
    Sequence number: 83
    Frame check sequence: 0xa06a35af [correct]
    QoS Control
        Priority: 5 (Video) (Video)
        ...0 .... = EOSP: Service period
        Ack Policy: Normal Ack (0x00)
        Payload Type: MSDU
        QAP PS Buffer State: 0x0
Logical-Link Control
Internet Protocol, Src: 192.168.100.1 (192.168.100.1), Dst: 192.168.202.198 
(192.168.202.198)
Transmission Control Protocol, Src Port: irdmi (8000), Dst Port: 32983 (32983), Seq: 
1449, Ack: 1, Len: 1448
Data (1448 bytes)

Now I'd like to prioritize frames from the desktop to the server as well.

After playing around with iptables & tc for a long time, I started to look 
into the code and a way I found to get my desktop to set the QoS 
Priority field is to use following iptables command:

desktop# iptables -t mangle -A POSTROUTING -p tcp --dport 8000 -j CLASSIFY --set-class 0:103

PPI version 0, 32 bytes
IEEE 802.11 QoS Data, Flags: .......TC
    Type/Subtype: QoS Data (0x28)
    Frame Control: 0x0188 (Normal)
    Duration: 44
    BSS Id: D-Link_f0:b1:3c (00:1b:11:f0:b1:3c)
    Source address: IntelCor_9e:db:5d (00:1d:e0:9e:db:5d)
    Destination address: D-Link_f0:b1:3c (00:1b:11:f0:b1:3c)
    Fragment number: 0
    Sequence number: 124
    Frame check sequence: 0xd60fe864 [correct]
    QoS Control
        Priority: 3 (Excellent Effort) (Video)
        Ack Policy: Normal Ack (0x00)
        Payload Type: MSDU
        Transmit Opportunity (TXOP) Limit Requested: 0x00
Logical-Link Control
Internet Protocol, Src: 192.168.202.198 (192.168.202.198), Dst: 192.168.100.1 (192.168.100.1)
Transmission Control Protocol, Src Port: 32983 (32983), Dst Port: irdmi (8000), Seq: 1, Ack: 1449, Len: 0

The argument '--set-class 0:103' is of course not really intuitive though after reading the code
it is clear why: they are magic! :)

wme.c: classify_1d

	/* skb->priority values from 256->263 are magic values to
	 * directly indicate a specific 802.1d priority.  This is used
	 * to allow 802.1d priority to be passed directly in from VLAN
	 * tags, etc.
	 */
	if (skb->priority >= 256 && skb->priority <= 263)
		return skb->priority - 256;


Trying the same trick as on the server with DSCP I had no success:

desktop# iptables -t mangle -A OUTPUT -p tcp --dport 8000 -j DSCP --set-dscp-class EF

No frame from the desktop has the QoS Priority field set. There is some code
in classify_1d which does something with DSCP but I haven't figured it out
how it is suppose to work.

So my question is, is my approach with iptables and DSCP supposed to work?

thanks,
daniel


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: QoS and DSCP
  2008-08-19  8:46 QoS and DSCP Daniel Wagner
@ 2008-08-19  9:04 ` Johannes Berg
  2008-08-19  9:11   ` Daniel Wagner
  0 siblings, 1 reply; 8+ messages in thread
From: Johannes Berg @ 2008-08-19  9:04 UTC (permalink / raw)
  To: Daniel Wagner; +Cc: linux-wireless

Daniel Wagner wrote:
> So my question is, is my approach with iptables and DSCP supposed to work?

The honest answer probably is: we don't know either, and it depends on the
drivers on both sides and the AP in the middle...

johannes

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: QoS and DSCP
  2008-08-19  9:04 ` Johannes Berg
@ 2008-08-19  9:11   ` Daniel Wagner
  2008-08-19 11:23     ` Daniel Wagner
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Wagner @ 2008-08-19  9:11 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless

Johannes Berg wrote:
> Daniel Wagner wrote:
>> So my question is, is my approach with iptables and DSCP supposed to work?
> 
> The honest answer probably is: we don't know either, and it depends on the
> drivers on both sides and the AP in the middle...

Ok. I'll try to poke a bit around in this area. Maybe I find something useful.

thanks anyway,
daniel

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: QoS and DSCP
  2008-08-19  9:11   ` Daniel Wagner
@ 2008-08-19 11:23     ` Daniel Wagner
  2008-08-19 12:05       ` Daniel Wagner
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Wagner @ 2008-08-19 11:23 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless

> Ok. I'll try to poke a bit around in this area. Maybe I find something 
> useful.

If I use --set-dscp with 0x18 (precedence level 3) instead of my orignial
--set-dscp-class EF (expedited forwarding) then I see the QoS Priority field
set to 3 (as with the CLASSIFY trick).

desktop# iptables -t mangle -A OUTPUT -p tcp --dport 8000 -j DSCP --set-dscp-class EF
-> no effect

desktop# iptables -t mangle -A OUTPUT -p tcp --dport 8000 -j DSCP --set-dscp 0x18
-> 
Frame 19 (174 bytes on wire, 174 bytes captured)
PPI version 0, 84 bytes
IEEE 802.11 QoS Data, Flags: .......TC
    Type/Subtype: QoS Data (0x28)
    Frame Control: 0x0188 (Normal)
    Duration: 44
    BSS Id: D-Link_f0:b1:3c (00:1b:11:f0:b1:3c)
    Source address: IntelCor_9e:db:5d (00:1d:e0:9e:db:5d)
    Destination address: D-Link_f0:b1:3c (00:1b:11:f0:b1:3c)
    Fragment number: 0
    Sequence number: 1224
    Frame check sequence: 0x321df371 [correct]
    QoS Control
        Priority: 3 (Excellent Effort) (Video)
        Ack Policy: Normal Ack (0x00)
        Payload Type: MSDU
        Transmit Opportunity (TXOP) Limit Requested: 0x00
Logical-Link Control
Internet Protocol, Src: 192.168.202.198 (192.168.202.198), Dst: 192.168.100.1 (192.168.100.1)
Transmission Control Protocol, Src Port: 46310 (46310), Dst Port: irdmi (8000), Seq: 1, Ack: 1449, Len: 0

Together with some printks I see that the code in wme.c classify_1d does
exactly the thing which it should. It returns the dscp value correctly.
Using --set-dscp 0x18 classify_1d returns 3 and with --set-dscp-class EF, 
classify_1d returns 5. That means there is a problem with mapping the result
of classify_1d to the correct QoS priority, right?

daniel


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: QoS and DSCP
  2008-08-19 11:23     ` Daniel Wagner
@ 2008-08-19 12:05       ` Daniel Wagner
  2008-08-19 13:44         ` [PATCH] Use only precedence level of DSCP field for frame classification Daniel Wagner
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Wagner @ 2008-08-19 12:05 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless

> Together with some printks I see that the code in wme.c classify_1d does
> exactly the thing which it should. It returns the dscp value correctly.
> Using --set-dscp 0x18 classify_1d returns 3 and with --set-dscp-class 
> EF, classify_1d returns 5. 

Crap, that's not correct. I think I found the problem:

static unsigned int classify_1d(struct sk_buff *skb)
{
        ...

	if (dscp & 0x1c)
		return 0;

	return dscp >> 5;
}

--set-dscp 0x28 (precendence level 5) classify_1d returns the correct
value 5. 

Setting with --set-dscp-class EF the TOS field it will have value 0xb8 (10111000b)
which maps to 
Bit 7-2: DSCP
Bit 1-0: ECN (expliliciet congestion notifaction)

So the question is what the 'if' is for? 

stay tuned!

daniel

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH] Use only precedence level of DSCP field for frame classification
  2008-08-19 12:05       ` Daniel Wagner
@ 2008-08-19 13:44         ` Daniel Wagner
  2008-08-19 13:59           ` Johannes Berg
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Wagner @ 2008-08-19 13:44 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless

Bit 4-5 of DSCP should not be considered by classify_d1. The
802.11 QoS Priority field is only depending on the precedence level.

Signed-off-by: Daniel Wagner <wagi@monom.org>
---
 net/mac80211/wme.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/wme.c b/net/mac80211/wme.c
index 4310e2f..7229e95 100644
--- a/net/mac80211/wme.c
+++ b/net/mac80211/wme.c
@@ -47,8 +47,6 @@ static unsigned int classify_1d(struct sk_buff *skb)
 		return 0;
 	}
 
-	if (dscp & 0x1c)
-		return 0;
 	return dscp >> 5;
 }
 
-- 
1.5.6.2


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] Use only precedence level of DSCP field for frame classification
  2008-08-19 13:44         ` [PATCH] Use only precedence level of DSCP field for frame classification Daniel Wagner
@ 2008-08-19 13:59           ` Johannes Berg
  2008-08-19 14:10             ` Daniel Wagner
  0 siblings, 1 reply; 8+ messages in thread
From: Johannes Berg @ 2008-08-19 13:59 UTC (permalink / raw)
  To: Daniel Wagner; +Cc: linux-wireless

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

On Tue, 2008-08-19 at 15:44 +0200, Daniel Wagner wrote:
> Bit 4-5 of DSCP should not be considered by classify_d1. The
> 802.11 QoS Priority field is only depending on the precedence level.

Mind explaining a bit more? I don't even know what DSCP really is, any
good reference?

johannes

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Use only precedence level of DSCP field for frame classification
  2008-08-19 13:59           ` Johannes Berg
@ 2008-08-19 14:10             ` Daniel Wagner
  0 siblings, 0 replies; 8+ messages in thread
From: Daniel Wagner @ 2008-08-19 14:10 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless

On Tue, Aug 19, 2008 at 03:59:38PM +0200, Johannes Berg wrote:
> On Tue, 2008-08-19 at 15:44 +0200, Daniel Wagner wrote:
> > Bit 4-5 of DSCP should not be considered by classify_d1. The
> > 802.11 QoS Priority field is only depending on the precedence level.
> 
> Mind explaining a bit more? I don't even know what DSCP really is, any
> good reference?

Sure. Cisco has a nice summery:

http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a00800949f2.shtml

In short DSCP supercedes the 'Type of Service' field in the IP header. 
It is backwarts compatible, that means prescedence field in TOS
maps to the DSCP precedence level.

The current code checks if the other bits of the TOS are all zero. This
ok for configuration which do only set the precedence level. But
RFC 2598 introduces the Expeddited Forwarding (EF) which sets some
of those lower bits. I think this test is not necessary and in the
case for EF even wrong.

daniel

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2008-08-19 14:10 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-19  8:46 QoS and DSCP Daniel Wagner
2008-08-19  9:04 ` Johannes Berg
2008-08-19  9:11   ` Daniel Wagner
2008-08-19 11:23     ` Daniel Wagner
2008-08-19 12:05       ` Daniel Wagner
2008-08-19 13:44         ` [PATCH] Use only precedence level of DSCP field for frame classification Daniel Wagner
2008-08-19 13:59           ` Johannes Berg
2008-08-19 14:10             ` Daniel Wagner

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).