Re: [rtcweb] Prioritization

Harald Alvestrand <> Fri, 25 April 2014 13:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9AABC1A04AE for <>; Fri, 25 Apr 2014 06:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ue8EJUQVb8yD for <>; Fri, 25 Apr 2014 06:21:29 -0700 (PDT)
Received: from ( [IPv6:2001:700:1:2::117]) by (Postfix) with ESMTP id A9C2C1A04B6 for <>; Fri, 25 Apr 2014 06:21:29 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA09D7C54D8 for <>; Fri, 25 Apr 2014 15:21:22 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UMXTTp7-jCTs for <>; Fri, 25 Apr 2014 15:21:22 +0200 (CEST)
Received: from (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by (Postfix) with ESMTPSA id 05DA27C54D5 for <>; Fri, 25 Apr 2014 15:21:22 +0200 (CEST)
Message-ID: <>
Date: Fri, 25 Apr 2014 15:21:21 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Prioritization
X-Mailman-Version: 2.1.15
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: Fri, 25 Apr 2014 13:21:33 -0000

On 04/25/2014 02:53 PM, Simon Perreault wrote:
> Le 2014-04-25 04:50, Harald Alvestrand a écrit :
>> A.4.  Changes from -03 to -04
>>     o  Added a section on prioritization, moved the DSCP section into it,
>>        and added a section on local prioritization, giving a specific
>>        algorithm for interpreting "priority" in local prioritization.
> Harald,
> The new text looks good. A comment about this part:
>> 			When an RTCWEB implementation has packets to send on multiple streams	
>> 			that are congestion-controlled under the same congestion controller,	
>> 			the RTCWEB implementation SHOULD serve the streams in a weighted	
>> 			round-robin fashion, with each stream at each level of priority being	
>> 			given approximately twice the transmission capacity (measured in	
>> 			payload bytes) of the level below.
> This looks like a QoS algorithm that might get quickly obsoleted by
> better ones. We don't want to prevent innovation in this matter by
> prescribing an obsolete QoS algorithm.
> Suggestion: leave it up to implementations to interpret priority levels
> however they want. Reword the current text so that it becomes an
> *example* of what an implementation might do.

The problem with doing that is that it leads to completely inconsistent 

The reason I wrote it this way is because the bandwidth estimation 
problem breaks down into two parts:

- Telling if it's a good idea to send a packet (congestion control)
- Deciding which packet to send (prioritization)

Congestion control is an active area of research and innovation. I said 
very little about it.

Prioritization is a different matter.

What I was trying to encapsulate was:

- Higher priority means more packets get sent
- "More" has a numeric value, so behaviour is predictable (that's where 
the x2 figure came from)
- Small packet flows get more packets than large-packet flows (counting 
bytes not packets)
- Lower priority flows can't be starved completely

This text captures that. I'd like to continue to capture that.