Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos

Wesley Eddy <> Wed, 10 July 2013 02:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5BAAC21F99CF for <>; Tue, 9 Jul 2013 19:56:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UPsVYCQIR0bm for <>; Tue, 9 Jul 2013 19:56:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A2C0721F9A35 for <>; Tue, 9 Jul 2013 19:56:42 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id r6A2ufQP026913 for <>; Tue, 9 Jul 2013 22:56:41 -0400
Received: from ([]) by (8.14.4/8.14.4) with ESMTP id r6A2uf5G019627 for <>; Tue, 9 Jul 2013 22:56:41 -0400
Received: (qmail 4575 invoked by uid 0); 10 Jul 2013 02:56:41 -0000
Received: from unknown (HELO ? ( by 0 with ESMTPA; 10 Jul 2013 02:56:41 -0000
Message-ID: <>
Date: Tue, 09 Jul 2013 22:56:36 -0400
From: Wesley Eddy <>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Cullen Jennings <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Jul 2013 02:56:54 -0000

On 7/8/2013 7:35 PM, Cullen Jennings wrote:
> The draft-dhesikan-tsvwg-rtcweb-qos draft was discussed extensively when it was an individual draft then WG draft in another WG and I don't think there is much more to say about it. This is one of the normative dependencies of the webrtc work and that stuff is already getting implemented in browsers so I want to move this along in an expedient fashion. 

Without checking ... it makes no sense to me that there would be
a normative dependency on this since it does not impact the
interoperability or correctness of an implementation.

It's purely a performance enhancement, if/when it actually causes
the intended things to happen in the network.

That said, I think the interesting facet of this document is that
packets within the same flow (defined by 5-tuple of address-port
pairs and protocol number) are receiving different codepoints, and
the implications of that for a CC that may be on top of them need
to be delved into.  There isn't really text or recommendations
going into that, which seems to be the important part, as if you
can figure that out, these mappings are the more obvious part.

So, I think it might make sense to do this, but the current
document isn't addressing the implications or how this works in
a bigger system sense, and I don't think the particular marking
tables are the hard or important part.

Wes Eddy
MTI Systems