Re: [rtcweb] DSCP marking for STUN packets

[Harald Alvestrand <[e-mail]>]

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 via lookup tables, not copying one field into another with 
different semantics (with or without bit-shift).

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