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

Dzonatas Sol <dzonatas@gmail.com> Tue, 20 September 2011 15:30 UTC

Return-Path: <dzonatas@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DBF21F8BD3 for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 08:30:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.821
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvBtcCfqUTEz for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 08:30:39 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2B6621F8C0D for <rtcweb@ietf.org>; Tue, 20 Sep 2011 08:30:38 -0700 (PDT)
Received: by ywa6 with SMTP id 6so536184ywa.31 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 08:33:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.42.156.133 with SMTP id z5mr759247icw.165.1316532784876; Tue, 20 Sep 2011 08:33:04 -0700 (PDT)
Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id dv19sm2665024ibb.3.2011.09.20.08.33.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 08:33:03 -0700 (PDT)
Message-ID: <4E78B2B5.7010904@gmail.com>
Date: Tue, 20 Sep 2011 08:35:17 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <CAEdus3LcjV9x+gLdZm5vwKhh-ge6xzfWSEB_NxcHe1Gz_5DZ8g@mail.gmail.com> <CAOhzyf=MqsgsGUi521oJ5N6+T+K1N01MjeHYPpX_VZK8uyQksw@mail.gmail.com> <CAKkvrEkx0mqnDWqNYse3r9WUMbYKNZhrBqQ0SPUAnTtKrA5bLg@mail.gmail.com> <CAOhzyf=_n3VhNi1GgxdKJpyzEMLORcKX2499+YZHQnGqYURxjg@mail.gmail.com> <CAKkvrEnXxoiJZJ3a3eg_Ybz0POCM+UTxU7nnWCf8Xt331jiXLA@mail.gmail.com> <4E787D56.8060106@alvestrand.no> <CAKkvrEnpMusPu8py2-98NffDY493z=tA_giW9X-p6c1LtgL+XA@mail.gmail.com> <4E788A9C.40105@alvestrand.no>
In-Reply-To: <4E788A9C.40105@alvestrand.no>
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-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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<harald@alvestrand.no>  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 http://tfwc.hackerslab.eu/ 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


-- 

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