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

Brian E Carpenter <> Wed, 13 August 2014 20:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B8D781A067F for <>; Wed, 13 Aug 2014 13:37:02 -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 BLNmQHS_SQuk for <>; Wed, 13 Aug 2014 13:37:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E189F1A024C for <>; Wed, 13 Aug 2014 13:37:00 -0700 (PDT)
Received: by with SMTP id rd3so308347pab.40 for <>; Wed, 13 Aug 2014 13:37:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5yuuynSYwncjkzMEHy+6Xto8OCKnCP4DKSoOCWbCxyY=; b=kIEd61d4ibdmY5nPDOHL+HV1biokru8W3ihpAnPpaOmnSjRejY9mPqg198FQM0dcMU fLHq9QIAMzlysdF/PYdzcSOEXeidiuos2VPYPnbYpeH94UeU7BnaarjkZs9htsAjnQBf cmshKmygMeD6MVhdmlf359Zp7jBen87HPXF/YOt9SJFsOaAagOZHDfcWIG30pefpt9GV dOiUAga2L4MRqjnQBN0Q93QptTyEMnkwc19Ze7vzaVnUWz1HndVIl263oH+/TlGDa7Rk hxiBPhNQmb4l8tF2jCae6Bz1H/5O0gwi3wnyEhppMAC3Htq46Jo9nYb/OQX3YLt8rYps 89zQ==
X-Received: by with SMTP id d15mr6259979pdj.48.1407962220567; Wed, 13 Aug 2014 13:37:00 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id gs2sm3016347pbc.20.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Aug 2014 13:37:00 -0700 (PDT)
Message-ID: <>
Date: Thu, 14 Aug 2014 08:37:04 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Dave Taht <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Dart] [rtcweb] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Aug 2014 20:37:03 -0000

On 13/08/2014 13:43, Dave Taht wrote:
> 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, 

Far from it. For example, if the host software is under the
illusion that CS1 selects the LE behaviour (RFC 3662) it
must be wrong to put it in the same hardware queue as CS2.
It it is also a false assumption that the CSx bits map
appropriately from other DSCP values - why should they?

If diffserv is correctly implemented at level 3, all
all packets should end up in the correct order in the
output queue and hardware classes shouldn't be used at
all IMHO.


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