Re: [rtcweb] Prioritization

Harald Alvestrand <> Fri, 02 May 2014 17:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 07FB11A6F88 for <>; Fri, 2 May 2014 10:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9a5txkR9q893 for <>; Fri, 2 May 2014 10:23:30 -0700 (PDT)
Received: from ( [IPv6:2001:700:1:2::117]) by (Postfix) with ESMTP id 7732E1A0911 for <>; Fri, 2 May 2014 10:23:30 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B060B7C52C0 for <>; Fri, 2 May 2014 19:23:25 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tUaBLvb8ZqW1 for <>; Fri, 2 May 2014 19:23:23 +0200 (CEST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id BFE807C521B for <>; Fri, 2 May 2014 19:23:23 +0200 (CEST)
Message-ID: <>
Date: Fri, 02 May 2014 19:23:23 +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: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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, 02 May 2014 17:23:34 -0000

On 04/30/2014 11:23 PM, Martin Thomson wrote:
> On 30 April 2014 14:09, Cullen Jennings (fluffy) <> wrote:
>> On Apr 25, 2014, at 11:03 AM, Matthew Kaufman (SKYPE) <> wrote:
>>> If a "lower priority" packet is dispatched before a "higher priority" packet in order to "prevent starvation", then what does "higher priority" mean?
>> I think the labels reflect what "might" happen on average and not for any particular packet.
> I think that Matthew was referring to the part where the browser is
> involved.  That is, the bit where, when presented with the option to
> send just one packet from buckets A through D, how does it choose from
> those buckets.
> The implication was that if A is more important than B, then if A
> wants to send, it gets to send.  Period.  The "prevents starvation"
> view of the world says that work is shared between A-D, with
> increasingly large proportions of the available capacity given to
> higher priority streams.  The problem with both these models is that
> they are crap in various ways.

I wouldn't use that word; it doesn't carry any information that I can

>   In one, you get cases where lower
> priority stuff never happens, even if that isn't what you wanted; in
> another, lower priority stuff can get resources, and that wasn't what
> you wanted.

So that's a better perspective: What range of things do you want to have

My thinking is that with variable-rate encoders, it is common and simple
to make do with less resources than you expected to have; it is more
complex to program for the case where transmission ceases totally for
some of the channels, some of the time.

So my argument for preferring round-robin schemes is that the case where
you don't want starvation to happen is more common than the case where
you want starvation to happen.

But reasonable people can disagree here.

> The DSCP markings and how they might interact with this are just an
> additional layer of uncertainty, primarily.
Hence the note about "under a common congestion controller" - if DSCP
markers are respected, having a common congestion controller covering
different DSCP classes doesn't make much sense - they don't "see" the
same network.

If they're not respected .... they could more usefully be grouped together.

> _______________________________________________
> rtcweb mailing list

Surveillance is pervasive. Go Dark.