Re: [rtcweb] Prioritization

Harald Alvestrand <harald@alvestrand.no> Fri, 25 April 2014 13:21 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AABC1A04AE for <rtcweb@ietfa.amsl.com>; Fri, 25 Apr 2014 06:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ue8EJUQVb8yD for <rtcweb@ietfa.amsl.com>; Fri, 25 Apr 2014 06:21:29 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id A9C2C1A04B6 for <rtcweb@ietf.org>; Fri, 25 Apr 2014 06:21:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id BA09D7C54D8 for <rtcweb@ietf.org>; Fri, 25 Apr 2014 15:21:22 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMXTTp7-jCTs for <rtcweb@ietf.org>; Fri, 25 Apr 2014 15:21:22 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 05DA27C54D5 for <rtcweb@ietf.org>; Fri, 25 Apr 2014 15:21:22 +0200 (CEST)
Message-ID: <535A6151.1060501@alvestrand.no>
Date: Fri, 25 Apr 2014 15:21:21 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca>
In-Reply-To: <535A5ACC.9070700@viagenie.ca>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/W_XoJDoW2B4PEzneXol8mh6ZxIo
Subject: Re: [rtcweb] Prioritization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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 
behaviour.

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.