Re: [rtcweb] DSCP marking for STUN packets

[Dave Taht <[e-mail]>]

On Thu, Mar 13, 2014 at 2:25 PM, Harald Alvestrand <[e-mail]> wrote:
> On 03/12/2014 09:35 AM, Dave Taht wrote:
>>
>> On Wed, Mar 12, 2014 at 3:55 AM, Justin Uberti <[e-mail]> wrote:
>>>
>>>
>>>
>>> On Tue, Mar 11, 2014 at 10:17 AM, Dave Taht <[e-mail]> wrote:
>>
>>
>>>>> Whether that always translates to "the highest DSCP code point" is ....
>>>>> a good question.
>>>>
>>>> It doesn't.  Keith added af42 support to mosh last year and had several
>>>> reports of packets being dropped with that marking. Worse the drops
>>>> happened
>>>> after 10 seconds of connectivity.
>>>>
>>>> Ecn markings on the other hand have thus far survived (if occasionally
>>>> stomped on) across the open internet in that protocol.
>>>
>>>
>>> This is a concern of mine as well, which is why we haven't yet flipped
>>> the
>>> switch to turn DSCP on by default in Chrome. I think we'll need to do
>>> some
>>> experimentation to see how often DSCP makes things worse.
>>
>> Well, while I'm at this, I note that how linux handles DSCP in WIFI
>> 802.11e
>> is generally suboptimal. the CS6 and CS7 bit patterns map to the VO
>> queue which is not aggregatable in wireless-n, CS4 and CS5
>> map to the VI queue which has a lot of good properties for videoconference
>> and voice traffic (but limited aggregation), and CS1 and CS2, which map
>> to the background queue, which has good aggregation but limited txops.
>
> That sounds like a Linux bug.... I would expect this translation to be done

That has existed since 802.11e was standardized in 2005.

> via lookup tables, not copying one field into another with different
> semantics (with or without bit-shift).

The diffserv codepoint IS preserved however it is classified into an 802.11e
queue based on the top 3 bits up until recently.

In linux 3.14 and later there is an optional classifier that does a diffserv
lookup to 802.11e queue translation.

These queues determine txop scheduling and bandwidth characteristics,
not drop probability.

http://en.wikipedia.org/wiki/IEEE_802.11e-2005#802.11e_MAC_protocol_operation

In some versions of cerowrt I have obsoleted the VO queue entirely,
pushed several AFxx markings into the VI queue, and respected
background markings to push them into the BK queue, and am working
on something that will try to maximize txops and aggregation by
"pushing" traffic into better queues when needed.

>
>>
>> I no longer have the bit patterns for AFxx memorized, but basically
>> all that was returned to the 802.11e classifier was dscp >> 5 up until
>> very
>> recently. Lastly, there really is no interpretation whatsoever of the AF
>> classes equating to "drop probability" in wifi (at least in lnux), they
>> merely
>> control queue selection and

I am not aware of any OS that translates AFxx markings into drop
probability directly on wifi.


>> it is generally better with wireless-n to aim for better aggregation in
>> one queue rather than using multiple queues as the cost of acquiring
>> the media dominates.


>>
>>
>>
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html