Re: [Dart] [rtcweb] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02

[Brian E Carpenter <[e-mail]>]

On 13/08/2014 13:43, Dave Taht wrote:
...
> It is kind of hard to wrap your head around how 802.11e actually
> works, but, this is a start:
> 
> http://en.wikipedia.org/wiki/IEEE_802.11e-2005#Enhanced_distributed_channel_access_.28EDCA.29
> 
> In linux wifi at least:
> 
> CS0, CS3 are mapped into the BE hw queue
> CS1, CS2 are mapped into the BK hw queue
> CS4, CS5 are mapped into the VI hw queue
> CS6, CS7 are mapped into the VO  hw queue
> 
> Bit patterns for the other classes to whatever extent they map into
> CSX are mapped into the underlying hardware queue.
> 
> I am not saying this is an optimal state of affairs, 

Far from it. For example, if the host software is under the
illusion that CS1 selects the LE behaviour (RFC 3662) it
must be wrong to put it in the same hardware queue as CS2.
It it is also a false assumption that the CSx bits map
appropriately from other DSCP values - why should they?

If diffserv is correctly implemented at level 3, all
all packets should end up in the correct order in the
output queue and hardware classes shouldn't be used at
all IMHO.

   Brian

> (as notably VO
> should be as completely disabled as possible in the 802.11n and ac
> age), and am very interested in how other OSes (ios, osx, windows),
> and router/switch OSes do it, but the wireless scheduling aspect of
> all these codepoints does not seem to be well touched upon.
> 
> On a personal note I tend to think that having 17+ ways to slice up
> traffic is about 13 or 14 too many, particularly those targetting a
> drop probability. When you have drop rates well below a few percentage
> points, adding another percentage point of granularity seems futile.
> 
> Lastly, there is also an implementation issue in linux presently in
> that doing extensive diffserv classification basically requires
> one iptables or tc rule per class, which is inefficient.  Someone (not
> me!) doing some code for doing diffserv saner there would go a long
> way...
>