Re: [MMUSIC] [rtcweb] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02

Dave Taht <> Tue, 12 August 2014 23:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 65B841A0A8D; Tue, 12 Aug 2014 16:56:54 -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 mmvFOxsHpewP; Tue, 12 Aug 2014 16:56:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5C8D1A079F; Tue, 12 Aug 2014 16:56:51 -0700 (PDT)
Received: by with SMTP id nu7so7848740obb.0 for <multiple recipients>; Tue, 12 Aug 2014 16:56:51 -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=TvOMDq5bVsm7hrc0pMtqzJ3nCKU6PoaHcLOkO23aYxw=; b=Q2edh9KLW9eYpiJj7ynYizJxi2kDLXhA+WMrRGDFSwuWjFjw6l7ID0T4Cg4ifLYflI 9krQwPRmtajzhKepJRPiSlzdXx726KuTAfhsHatbGMn2PfyKAhIOjoWJ27DuD5y/A53P PbBoP81QEVdyfvvvWR+QdV0mYtj+A0i99lN7eVoE+OCrf6UcJ3EuE1I5sJw/CxQVrurK gV3yjCrAWpFCOV+tm+2rpCZZpgVDtgUDTu1gC4rdWCmoxN0AKcgu1WZGgiZm1gEsMV37 1KinnXCsG9qOV6vcurtE3jA6biqj7Ww9hH7tH+XHpMIS5p83eAeiKksRp4xThpJgT3y9 f1VQ==
MIME-Version: 1.0
X-Received: by with SMTP id s8mr1039793oev.5.1407887811135; Tue, 12 Aug 2014 16:56:51 -0700 (PDT)
Received: by with HTTP; Tue, 12 Aug 2014 16:56:51 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 12 Aug 2014 16:56:51 -0700
Message-ID: <>
From: Dave Taht <>
To: Ben Campbell <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 12 Aug 2014 21:52:10 -0700
Cc:,, "" <>,, "" <>, "" <>, "" <>
Subject: Re: [MMUSIC] [rtcweb] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Aug 2014 23:56:54 -0000

This is also of some interest to me at least, and perhaps some members
of the AQM working group who are working out weighted fair queuing and
wred like approaches to these needs.

Anyway, I do try to track thinking in this area in the ongoing
development of cerowrt's sqm system, which has pluggable modules for
all the known aqm and fq schedulers, and a three tier system modeled
on wondershaper for managing traffic,
which uses what diffserv markings that I have observed make sense...

Some relevant links:

Missing from this discussion so far is what is actually deployed out
there... I am only familiar with stuff like the above as an
egress/ingress queue management system...

AND: in the case of linux based wireless routers, none of the AF
codepoints are respected explicitly, and how the codepoints are mapped
are described by 802.11e - and that is far more about scheduling
priority for airtime rather than drop probability.

It is kind of hard to wrap your head around how 802.11e actually
works, but, this is a start:

In linux wifi at least:

CS0, CS3 are mapped into the BE hw queue
CS1, CS2 are mapped into the BK hw queue
CS4, CS5 are mapped into the VI hw queue
CS6, CS7 are mapped into the VO  hw queue

Bit patterns for the other classes to whatever extent they map into
CSX are mapped into the underlying hardware queue.

I am not saying this is an optimal state of affairs, (as notably VO
should be as completely disabled as possible in the 802.11n and ac
age), and am very interested in how other OSes (ios, osx, windows),
and router/switch OSes do it, but the wireless scheduling aspect of
all these codepoints does not seem to be well touched upon.

On a personal note I tend to think that having 17+ ways to slice up
traffic is about 13 or 14 too many, particularly those targetting a
drop probability. When you have drop rates well below a few percentage
points, adding another percentage point of granularity seems futile.

Lastly, there is also an implementation issue in linux presently in
that doing extensive diffserv classification basically requires
one iptables or tc rule per class, which is inefficient.  Someone (not
me!) doing some code for doing diffserv saner there would go a long

On Sat, Aug 9, 2014 at 11:48 AM, Ben Campbell <> wrote:
> Hi,
> The DART working group has started a last call for draft-ietf-dart-dscp-rtp-02, ending on August 22. This informational draft describes considerations for the use of DiffServ code points in situations where one multiplexes multiple RTP packet streams, and potentially other protocol streams, that share the same 5-tuple.
> Since this draft is likely of interest to several working groups, I would like to solicit additional reviews from participants of TSVWG, AVTCORE, MMUSIC, CLUE, RTCWEB, and RMCAT. Please send any feedback (including feedback to the effect of "this is ready to progress") to the DART working group mailing list.
> Thanks!
> Ben.
> Begin forwarded message:
>> Resent-From:
>> From: Ben Campbell <>
>> Subject: WGLC: draft-ietf-dart-dscp-rtp-02
>> Date: August 9, 2014 at 12:50:16 PM CDT
>> Resent-To:,,
>> To:
>> Cc:,, Richard Barnes <>
>> This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. It's available on the data tracker at the following URL:
>> The WGLC will conclude on 22 August, 2014. Please send your comments to the authors and the DART mailing list. If you've reviewed it and think it's good to go, please say so.
>> Thanks!
>> Ben.
> _______________________________________________
> rtcweb mailing list

Dave Täht