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

Randell Jesup <> Tue, 20 September 2011 15:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 238D021F8C26 for <>; Tue, 20 Sep 2011 08:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.614
X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qh24f5--zvfj for <>; Tue, 20 Sep 2011 08:52:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF5E921F8C00 for <>; Tue, 20 Sep 2011 08:52:50 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1R62fE-0001nV-Lm for; Tue, 20 Sep 2011 10:55:16 -0500
Message-ID: <>
Date: Tue, 20 Sep 2011 11:51:52 -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
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 -
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 15:53:16 -0000

On 9/20/2011 8:44 AM, Harald Alvestrand wrote:
> On 09/20/11 14:36, Soo-Hyun Choi wrote: 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 agree with Harald here; the entire algorithm doesn't need to run on 
the sender side alone.  An RFC can contain algorithms for calculating 
values (see RTCP jitter for an example), but I think here we want to 
make sure that the mechanisms we provide allow things to work when the 
implementations at the send and receive side are different.  For 
example, for the classic one-stream CC model like Google/GIPS's 
algorithm their use of TMMBR - it should work with anyone supporting 
TMMBR.  In our case we may find we need to add a new FB message, since 
the existing ones may not cover what we need to convey (and we probably 
don't want to go the RTCP APP route).  Or we may find it makes most 
sense to use a RTP header extension.  We'll see.

>> 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.

Agree (mostly) with Harald there, but I agree we don't want to specify 
the CC algorithm in total.  We may very well want to document a proposed 
baseline algorithm that meets the requirements we lay down in the spec, 

Randell Jesup