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

Harald Alvestrand <harald@alvestrand.no> Wed, 21 September 2011 08:21 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 11E7C21F8C9A for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 01:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.494
X-Spam-Level:
X-Spam-Status: No, score=-108.494 tagged_above=-999 required=5 tests=[AWL=2.105, 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 zFfM5cCb82rO for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 01:21:05 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 68D6321F8CA5 for <rtcweb@ietf.org>; Wed, 21 Sep 2011 01:21:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6B1A739E0A7; Wed, 21 Sep 2011 10:23:29 +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 RauMMkut1yCe; Wed, 21 Sep 2011 10:23:28 +0200 (CEST)
Received: from [192.168.0.2] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C7B3939E088; Wed, 21 Sep 2011 10:23:28 +0200 (CEST)
Message-ID: <4E799F00.8030602@alvestrand.no>
Date: Wed, 21 Sep 2011 10:23:28 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: Soo-Hyun Choi <s.choi@computer.or.kr>
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> <CAKkvrEk0_L6UfDsUHQea_5XXfYXGWQ-8dJm_mP+nTSeVeL90rQ@mail.gmail.com>
In-Reply-To: <CAKkvrEk0_L6UfDsUHQea_5XXfYXGWQ-8dJm_mP+nTSeVeL90rQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
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: Wed, 21 Sep 2011 08:21:06 -0000

On 09/21/2011 09:59 AM, Soo-Hyun Choi wrote:
> Harald,
>
>>> 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?
> Sure - one may not need to send the receiver report every so often
> when network is stable. But the question is "how long stable is
> stable?". Perhaps, the definition of "stable" might fall into
> unquantifiable term, too? Anyway, when I said "quickly", I meant "at
> least once in an every RTT" (borrowing from the TCP SACK analogy), in
> which the use of the standard RTCP RR is not suitable in this level of
> granularity.
I think receiver->sender reporting every RTT (or every packet, which is 
frequently less frequent) is overkill, but that's a statement with a lot 
of gut feeling and very few numbers behind it.

One advantage we have in RTCWEB is that we can assume that if audio and 
video work OK across the network, we're in a good place. We don't have 
to worry about getting gigabyte file transfers to utilize 90% of the 
link - even thogh we have to worry about audio and video functioning 
while those gigabyte transfers are taking place.
>>> 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.
>>
> Question: Isn't your draft also proposing a new CC mechanism in the
> context of RTCWEB?
No, to quote from the draft:

    It is published to aid the discussion on mandatory-to-implement flow
    control for RTCWEB applications; initial discussion is expected in
    the RTCWEB WG's mailing list.

It's describing an algorithm that already exists outside of the IETF. It 
seems to have succeeded in stimulating the discussion.
If the conclusion of the discussion is that something along these lines 
should be standardized, I hope the ADs and chairs of the IETF can give 
us guidance on where the discussion of this standardization should take 
place.