Re: [rtcweb] Protesting the QoS document decision

"Subha Dhesikan (sdhesika)" <> Thu, 14 November 2013 20:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9270A11E810D for <>; Thu, 14 Nov 2013 12:54:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 551Kz-3rjINM for <>; Thu, 14 Nov 2013 12:54:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9AE0911E8133 for <>; Thu, 14 Nov 2013 12:54:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4206; q=dns/txt; s=iport; t=1384462473; x=1385672073; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/rLdVOi5RXN5jJFM7shz98dgFPIHBcokLVMCewXgkdA=; b=YXcY5que38Vb/aP8bT2euJOr//kSS3h1BQ2YRWEXxyBquLJCJej7NAzR ngk1KfdhxlMZ+VMrRtaZPRWx/MhqlqDOh2AcYsCmX+T4nl7VoKeJSuOfx CXZmsQ4ri+Zf9gsu4ZYQ6CXqUKA/9GCt5EydkiWguWgjj2XdKZqiwgLhF U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.93,701,1378857600"; d="scan'208";a="281968984"
Received: from ([]) by with ESMTP; 14 Nov 2013 20:54:32 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rAEKsV3K005459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 20:54:31 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 14:54:31 -0600
From: "Subha Dhesikan (sdhesika)" <>
To: Gonzalo Camarillo <>, Ted Hardie <>
Thread-Topic: [rtcweb] Protesting the QoS document decision
Date: Thu, 14 Nov 2013 20:54:30 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:54:37 -0000

Thanks Gonzalo.  I am sorry I am coming in late ...

- I was asked to move the document from RTCWEB to TSVWG and here is an email I posted to announce that it has moved in TSVWG.
It seems like I did not post a similar thread to RTCWEB.   

- I am aware that there are concerns regarding the draft due to the bundling of flows.  I did not update the draft for Vancouver because I was looking for the outcome or discussions regarding bundling in RTCWeb.  The update I am looking to provide (but will have discussions with people who have expressed this objection) is that this QoS draft will not get into bundling issues. The application will provide the priority, the suggestion of how to translate them into the DSCP value  or other values will be the focus of the draft.  
In the bundling discussion, Dan Drutta, co-author of this draft raised an issue that bundling should take priority into account. That viewpoint will continued to be expressed but outside this draft.

- The other reason that this draft was not updated is because we were waiting on the priority tags to be defined from the application to the browser. This was done recently in W3C. 

So, a new draft will go out by the end of the month. I would very much like to understand why/how this draft has caused a dependency on implementations. I am happy to work with other authors to remove any roadblocks this draft is causing.


-----Original Message-----
From: Gonzalo Camarillo [] 
Sent: Thursday, November 14, 2013 11:28 AM
To: Ted Hardie
Cc: Wesley Eddy; Harald Alvestrand;;;; Subha Dhesikan (sdhesika)
Subject: Re: [rtcweb] Protesting the QoS document decision


[adding Subha, the main author of the draft, to the cc:]

Subha intends to revise the draft before the end of this month. She will try and address the comments below from Wes.



On 14/11/2013 8:38 PM, Ted Hardie wrote:
> On Thu, Nov 14, 2013 at 9:19 AM, Wesley Eddy < 
> <>> wrote:
>     On 11/14/2013 3:10 AM, Gonzalo Camarillo wrote:
>     As for the current status, the document does not yet address
>     core issues that have been pointed out.  See, for instance:
>     People interested should work on this in TSVWG.  There does not
>     seem to be any reason for RTCWEB to be gated on it, as it has zero
>     impact on interoperability or the protocol.  Having a normative
>     reference to it is not correct and is easy to fix.
>     --
>     Wes Eddy
>     MTI Systems
> Hi Wes,
> The issue raised isn't that there is an RTCWEB document gated on it, 
> but that shipping code does require this to be resolved.  The message 
> you point to above notes a core issue, which I assume is this:
> 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.
> I think the authors may not have seen "interesting facet" 
> as a clear enough signal that they were blocked on this.  
> 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?
> You may want to include pointers on why having this situation,
> versus multiple flows going between the same end points in
> other contexts, is a problem.  I'm kind of concerned as well that they 
> will take the simple solution (use the most stringent
> QoS), which is clear enough from a congestion control perspective
> but bad from other perspectives.
> regards,
> Ted