Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)

Randell Jesup <> Mon, 19 September 2011 07:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F52721F8A7A for <>; Mon, 19 Sep 2011 00:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.515
X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8bzMPJdp21NX for <>; Mon, 19 Sep 2011 00:55:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8110121F8A66 for <>; Mon, 19 Sep 2011 00:55:43 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1R5Yjt-0001QP-25; Mon, 19 Sep 2011 02:58:05 -0500
Message-ID: <>
Date: Mon, 19 Sep 2011 03:54:44 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: Stefan Holmer <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------050407030409030209020507"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Cc: Randell Jesup <>,
Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)
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: Mon, 19 Sep 2011 07:55:44 -0000

Open question to the list: should the congestion-control-geeks discuss 
here on the
list the nitty-gritty details required to build the requirements and 
especially to design
and debate a possible proposed "baseline" congestion-control algorithm?

We can certainly do that detailed discussion by email and come back with a
draft;  I had been planning to do it by email, but recent discussion on 
made me think I should ask for opinions on this.  Given the structure, 
if there's
any significant support for "on-the-list" I'll do that.  Realize though 
that they may
get pretty long and detailed without really touching on the larger 
issues being
discussed here.

Right now the bof members to discuss this and propose a draft would be 
Harald, Justin,  Stefan Holmer and Magnus.

On 9/19/2011 3:06 AM, Stefan Holmer wrote:
> On Mon, Sep 19, 2011 at 12:10 AM, Randell Jesup 
> < <>> wrote:
>     On 9/16/2011 9:26 AM, Magnus Westerlund wrote:
>         1. Section 3: As delay based congestion control has been tried
>         a number
>         of times and meet with less than stellar success I wonder if
>         you have
>         any understanding of how this relates to the issues previously
>         encountered:
>     Do you have any pointers to these earlier attempts?  My separate
>     experience
>     with this class has been extremely successful, though perhaps with
>     a set of
>     real-world use-cases that don't cover the situations you're
>     referring to.
>     My understanding is that Radvision's NetSense is very similar from
>     their
>     description of it.
> I'm interested in any references you may have as well.

I doubt you'll find many/any, as the first published discussion I saw of 
congestion control for RTP data was Radvision's posts about Netsense 
last year
and in their Android webcasts; and  that was pretty detail-free until 
their recent
blog posts.  There's plenty of un-published experience with them at 
various companies
I believe....  Not just Google and Radvision.

>         - Stability (especially on short RTTs)
>         - How it competes with TCP flows, which was a real issues for
>         TCP Vegas
>         but may be less of an issue here.
>     Perhaps Google can comment here about what tests they've done.  If
>     anything,
>     this class of algorithm when faced with aggressive TCP flows will
>     eventually
>     have problems, because TCP will tend to fill up the buffers at the
>     bottleneck.
>     Since this algorithm senses buffers starting to fill up, it will
>     tend to back
>     off before TCP is likely to see a loss event.  Now, it's more
>     complex than
>     that of course, and multiple flows make it more complex still.
>      It's also
>     sensitive to the adaptation rate of this algorithm and speed of
>     backoff.
>     If I remember, TFRC tends to back off more slowly than TCP but
>     also increase
>     more slowly; I suspect Google's algorithm is similar.
> As you're saying, it will always be hard for delay based congestion 
> control algorithms to compete with a packet loss based algorithm. The 
> delay based algorithm will detect over-use much earlier than the 
> packet loss based one, and that's basically what we've seen in the 
> tests we've been running as well. I do think we would benefit from 
> more tests in this area. For instance, we might want to go with an 
> additive increase approach rather than the current one which is 
> multiplicative, this would likely help improve the algorithms self 
> fairness as well.

Probably; additive increase is probably better, or possible using a 
predicted-bandwidth increase.  If you use additive increase, it should 
probably be
partly proportional to the maximum "good" bandwidth seen during the 
This provides some needed scaling of the ramp-up rate to the absolute 
of bandwidth available.

Randell Jesup