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

Harald Alvestrand <harald@alvestrand.no> Tue, 20 September 2011 11:45 UTC

Return-Path: <harald@alvestrand.no>
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 B9B3A21F8B75 for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 04:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.599
X-Spam-Level:
X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 6jFcSGcv2dcZ for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 04:45:12 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1A45C21F8B70 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 04:45:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3366D39E0BC for <rtcweb@ietf.org>; Tue, 20 Sep 2011 13:47:35 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQigqUXjrpTv for <rtcweb@ietf.org>; Tue, 20 Sep 2011 13:47:34 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id CE9A939E08A for <rtcweb@ietf.org>; Tue, 20 Sep 2011 13:47:34 +0200 (CEST)
Message-ID: <4E787D56.8060106@alvestrand.no>
Date: Tue, 20 Sep 2011 13:47:34 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.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>
In-Reply-To: <CAKkvrEnXxoiJZJ3a3eg_Ybz0POCM+UTxU7nnWCf8Xt331jiXLA@mail.gmail.com>
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-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 11:45:12 -0000

On 09/20/11 09:07, Soo-Hyun Choi wrote:
> Well, the problem of the inaccurate feedback timer is that it could
> make the whole things go wrong.
>
> 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.
>
> Wouldn't we need to be a little more careful on choosing/designing CC
> algos, which I believe we are capable of?
>
One prayer....

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.

              Harald