Re: [rtcweb] DSCP marking for STUN packets

Dave Taht <> Fri, 14 March 2014 12:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 105421A00B1 for <>; Fri, 14 Mar 2014 05:32:46 -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 JanTpep4WIG0 for <>; Fri, 14 Mar 2014 05:32:43 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22c]) by (Postfix) with ESMTP id EECCC1A0133 for <>; Fri, 14 Mar 2014 05:32:41 -0700 (PDT)
Received: by with SMTP id m15so2048472wgh.15 for <>; Fri, 14 Mar 2014 05:32:34 -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=H28c7rjIHPIVFRP99Rwp+nUdL9i0E5nRh8EH5A5uZAk=; b=gqUHaAR05DQCJvQxj0YfYq7+oHjRVbJoR5h26n4q9MJZDWznY6ZWvecI1nwFVA2Wk1 DO7SQKLCVZI9NnyHk6H5SEl9OaKR6zY/SJI+iVpMw9uIYRFI/b7R2GgrZQCfz+nMYF/G 7E0TJdSQUXUXHZUyg4JV9B/BrLsWW3RRTfCX2DzlkmMhrvc0nWJp+LQ/lTlMhTSdwLY4 v/VPmHJtU5H/l9mfCSRypxS6nY0YFoRnVt+KhPWq0xfF3C8NGnpKpdGv33+KP991wR7U b6Xt5UZ7FwuqJXlZtiL6TGFPFeyHQH8bws9kpIM0YzEitF9OrPfExfW8eoY0OT+sDho/ GKXw==
MIME-Version: 1.0
X-Received: by with SMTP id gj9mr6005761wic.17.1394800354730; Fri, 14 Mar 2014 05:32:34 -0700 (PDT)
Received: by with HTTP; Fri, 14 Mar 2014 05:32:34 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Fri, 14 Mar 2014 05:32:34 -0700
Message-ID: <>
From: Dave Taht <>
To: Harald Alvestrand <>
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: Fri, 14 Mar 2014 12:32:46 -0000

On Thu, Mar 13, 2014 at 2:25 PM, Harald Alvestrand <> wrote:
> On 03/12/2014 09:35 AM, Dave Taht wrote:
>> 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.
> 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.

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: