Re: [rtcweb] Protesting the QoS document decision

Wesley Eddy <> Thu, 14 November 2013 20:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CD8B11E810D for <>; Thu, 14 Nov 2013 12:19:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.937
X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mgXz4MPXgYjA for <>; Thu, 14 Nov 2013 12:19:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A696D11E8119 for <>; Thu, 14 Nov 2013 12:19:04 -0800 (PST)
Received: from ([]) by (8.14.4/8.14.4) with ESMTP id rAEKJ1ad018536 for <>; Thu, 14 Nov 2013 15:19:01 -0500
Received: (qmail 7467 invoked by uid 0); 14 Nov 2013 20:19:01 -0000
Received: from unknown (HELO ? ( by 0 with ESMTPA; 14 Nov 2013 20:19:00 -0000
Message-ID: <>
Date: Thu, 14 Nov 2013 15:18:50 -0500
From: Wesley Eddy <>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Ted Hardie <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "" <>, "" <>,
Subject: Re: [rtcweb] Protesting the QoS document decision
X-Mailman-Version: 2.1.12
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: Thu, 14 Nov 2013 20:19:09 -0000

On 11/14/2013 1:38 PM, Ted Hardie wrote:
> The issue raised isn't that there is an RTCWEB document gated on it, but
> that shipping code does require this to be resolved.

Hi Ted, it probably doesn't matter if I don't understand, but
it seems dubious to me that any shipping code could be held
up over this.  Codebases don't need to set DSCP in the same
way, plus we've always been told that RTCWEB codebases are
easy to upgrade.  Anyone can ship code setting the DSCPs in
whatever way they want to, and there will be no interop issues.

> The message you
> point to above notes a core issue, which I assume is this:
> ...

Actually, there are others.  It was pointed out on the TSVWG list
that the actual mappings recommended in the document are not going
to work well.  For instance, see:

> I think the authors may not have seen "interesting facet" 
> as a clear enough signal that they were blocked on this.

I don't know if they're really "blocked" on this though ... I've
just brought it up as a comment.

> Can you restate this problem to them, so that they understand either
> where in the document they should raise the issue or where there is work they can reference
> for incorporation?

IMO, this is a fundamental issue with the recommendation that
differs from the way that DiffServ is implemented and thought
about.  Classifiers operate based on flow-level n-tuple
information generally.  The document pretends that what it's
prescribing is perfectly normal, which I don't think is the case,
and I don't know if it's even something the IETF wants to do.

Wes Eddy
MTI Systems