Re: [rtcweb] DSCP marking for STUN packets

[Dave Taht <[e-mail]>]

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.

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.



-- 
Dave Täht

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