Re: [rtcweb] DSCP marking for STUN packets

Dave Taht <> Wed, 12 March 2014 08:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C3BF51A091F for <>; Wed, 12 Mar 2014 01:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nSgmnyWv1AxE for <>; Wed, 12 Mar 2014 01:35:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::231]) by (Postfix) with ESMTP id 7B7A51A0915 for <>; Wed, 12 Mar 2014 01:35:36 -0700 (PDT)
Received: by with SMTP id cc10so1987660wib.16 for <>; Wed, 12 Mar 2014 01:35:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kxKRj2Jkign9Jl1xk2vG1qbNYDbKHA1DVoFkHjRsBm8=; b=KYvUd4VE6FiyNYz33zgfDiMZJZyZLX6Q+pV3Wmn0ShufP2Nih2ZGgmoEl3dNqeNkpE /IgCG3av9yYr/md4YQ/sKXpR/LrH3WbnbnEhb4RS7gIivVoboA48FYJXv6hlW80EYisa abWjFRf4Eeo875CJevhH5UQ7B/jMLOM0Us+Jnh8PJCO7DVuUoELzKskonIbKnopkp2dr Rz+QATAy21uqbyX4inSlGsPrJFHFXKxq/TIyx0P1uxFAPZpC7XV3YO6sJrsjDcHfL7PM yYRJavpvZ9gejMq3Ov77v7qVPYqxOAVsScxq5yxLXju/MQaooHQ1lsRpkxxDGCGd14pB FD3g==
MIME-Version: 1.0
X-Received: by with SMTP id g17mr191298wjs.72.1394613329985; Wed, 12 Mar 2014 01:35:29 -0700 (PDT)
Received: by with HTTP; Wed, 12 Mar 2014 01:35:29 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Wed, 12 Mar 2014 08:35:29 +0000
Message-ID: <>
From: Dave Taht <>
To: Justin Uberti <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Keith Winstein <>, "" <>
Subject: Re: [rtcweb] DSCP marking for STUN packets
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Mar 2014 08:35:39 -0000

On Wed, Mar 12, 2014 at 3:55 AM, Justin Uberti <> wrote:
> On Tue, Mar 11, 2014 at 10:17 AM, Dave Taht <> 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: