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

Harald Alvestrand <> Tue, 20 September 2011 12:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF5EE21F84B3 for <>; Tue, 20 Sep 2011 05:41:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -108.663
X-Spam-Status: No, score=-108.663 tagged_above=-999 required=5 tests=[AWL=1.936, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2ynKV69QV-fP for <>; Tue, 20 Sep 2011 05:41:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C979B21F84A9 for <>; Tue, 20 Sep 2011 05:41:47 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C9BD39E0BC; Tue, 20 Sep 2011 14:44:13 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5TA4dZT76j8y; Tue, 20 Sep 2011 14:44:12 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTPS id 9313A39E08A; Tue, 20 Sep 2011 14:44:12 +0200 (CEST)
Message-ID: <>
Date: Tue, 20 Sep 2011 14:44:12 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Soo-Hyun Choi <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Tue, 20 Sep 2011 12:41:48 -0000

On 09/20/11 14:36, Soo-Hyun Choi wrote:
> Harald,
> On Tue, Sep 20, 2011 at 20:47, Harald Alvestrand<>  wrote:
>> let's avoid unquantifiable terms in our discussions. "A little more careful"
>> is an unquantifiable term.
>> If we want to say "I think the algorithm must guarantee that the bandwidth
>> estimate is updated within 1.5 seconds when the available bandwidth changes
>> from 2 Mbit/sec to 1 Mbit/sec", let's say something like that - focus on
>> what the requirements are.
>> We can always be a little more careful. But it doesn't tell us when we're
>> close enough.
> Sorry if my previous email looked that way to you (of course, I didn't
> mean to just pray for the mere hope). I was talking about some general
> CC principles in the high level for real-time interactive multimedia
> applications, like some of us did too in this thread.
Sorry, not intended to point at anyone in particular - I have been 
worried about several conversations that seemed to be straying very far 
from the "brass tacks" here.
> One of the critical metrics of a delay-based CC algo is an accurate
> measurement of inter-packet interval (IPI) and timely report of IPI to
> the sender so it can update the send rate correctly, which we all
> agreed in this email thread. Although everyone in this list seemed to
> aware of this, I have highlighted again that the relatively
> course-grained RTCP carrying the IPI measurement data can cause
> instability at the encoder's output bitrate due to the following
> reason.
The draft's suggestion is to avoid the need for communicating all the 
IPI information from the receiver to the sender by doing part of the 
processing and estimation at the receiver. I think we need to send the 
resulting information quickly when it changes, but don't need to send it 
so often when it remains stable. What "quickly" means in this context is 
a good question - 0.1 second? 1 second? Certainly less than 5 seconds?
>> I.e., Inaccurate BW estimation could lead into providing inaccurate
>> information about the available BW to the upper layer, which
>> eventually result in instability at the codec's encoding rate.
> So, my original question/suggestion was why not use AVPF (which is
> smaller packet than the standard RTCP) to generate/report more
> frequently to the sender in your algorithm. Or alternatively, I have
> already designed a window-version's of TFRC that re-introduces a
> TCP-like Ack-clocking, so-called TFWC (TCP-Friendly Window-based CC),
> which performs reasonably well (as good as TFRC) for the similar
> situations (RTC environment).
> I would like to ask to this list (or Harald) if suggesting alternative
> CC algo idea could fit into the RTCWEB Charter's scope - if so, I
> could elaborate more by writing an I-D or so. In the mean time, you
> could check my document at if you are
> interested.
I am certainly looking for input on where we can best have this 
discussion, too!
Algorithm design is outside of RTCWEB's charter, but I think 
requirements/criteria for what "good enough" means for RTCWEB is inside it.