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

Dzonatas Sol <> Tue, 20 September 2011 15:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 00DBF21F8BD3 for <>; Tue, 20 Sep 2011 08:30:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.821
X-Spam-Status: No, score=-3.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vvBtcCfqUTEz for <>; Tue, 20 Sep 2011 08:30:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E2B6621F8C0D for <>; Tue, 20 Sep 2011 08:30:38 -0700 (PDT)
Received: by ywa6 with SMTP id 6so536184ywa.31 for <>; Tue, 20 Sep 2011 08:33:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=vDE+AYWJ05lArcolmI5lJu/0qgxOzpOmdDRVHV0wADY=; b=OdulEXPg04nP3YLJ+cEhkODtSAneL5j1v2NC6FJCTCsoi6xgbC/cdbV7B2ZEszEL1b tGcz9uBvQU2Qqrrrht9Fg9nvRXvGHO5jlVt96BPU2jNKurGqp/ij+Hkz/gYP6VK4pu9z Zxq28KxLH60Sunq1DLIULL0im+PfNdzLGJ8RU=
Received: by with SMTP id z5mr759247icw.165.1316532784876; Tue, 20 Sep 2011 08:33:04 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id dv19sm2665024ibb.3.2011. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 08:33:03 -0700 (PDT)
Message-ID: <>
Date: Tue, 20 Sep 2011 08:35:17 -0700
From: Dzonatas Sol <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110818 Icedove/3.0.11
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; 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 15:30:40 -0000

On 09/20/2011 05:44 AM, Harald Alvestrand wrote:
> 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?

In the context of RTCWEB, I have constrained the meaning of quick to an 
ICE path. Or, any information known *before* the duration of any session 
is "quick", yet that does not include any actual connection delay.

>>> 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.
> _______________________________________________
> rtcweb mailing list


<i>The wheel.</i metro-link=t dzonatasolyndra>