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

Soo-Hyun Choi <soohyun.choi@cl.cam.ac.uk> Tue, 20 September 2011 07:05 UTC

Return-Path: <s.choi@daemon.or.kr>
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 6E78A21F8906 for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 00:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 4va41pRj9QAD for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 00:05:40 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 49CD421F88B7 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 00:05:39 -0700 (PDT)
Received: by fxd18 with SMTP id 18so256139fxd.31 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 00:08:04 -0700 (PDT)
Received: by 10.223.18.149 with SMTP id w21mr769949faa.118.1316502483973; Tue, 20 Sep 2011 00:08:03 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by mx.google.com with ESMTPS id y8sm634128faj.10.2011.09.20.00.07.55 (version=SSLv3 cipher=OTHER); Tue, 20 Sep 2011 00:07:58 -0700 (PDT)
Received: by bkaq10 with SMTP id q10so224373bka.31 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 00:07:55 -0700 (PDT)
Received: by 10.204.142.145 with SMTP id q17mr257938bku.275.1316502475276; Tue, 20 Sep 2011 00:07:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.205.81.10 with HTTP; Tue, 20 Sep 2011 00:07:35 -0700 (PDT)
In-Reply-To: <CAOhzyf=_n3VhNi1GgxdKJpyzEMLORcKX2499+YZHQnGqYURxjg@mail.gmail.com>
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>
From: Soo-Hyun Choi <soohyun.choi@cl.cam.ac.uk>
Date: Tue, 20 Sep 2011 16:07:35 +0900
Message-ID: <CAKkvrEnXxoiJZJ3a3eg_Ybz0POCM+UTxU7nnWCf8Xt331jiXLA@mail.gmail.com>
To: Henrik Lundin <hlundin@google.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Randell Jesup <randell-ietf@jesup.org>, 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: Tue, 20 Sep 2011 07:05:41 -0000

On Tue, Sep 20, 2011 at 14:58, Henrik Lundin <hlundin@google.com> wrote:
>
>
> On Tue, Sep 20, 2011 at 7:37 AM, Soo-Hyun Choi <soohyun.choi@cl.cam.ac.uk>
> wrote:
>>
>> A question and a suggestion.
>>
>>
>>
>> >>>>
>> >>>> 4. Section 4.
>> >>>>
>> >>>> "This algorithm is run every time a receive report arrives at the
>> >>>>    sender, which will happen [[how often do we expect? and why?]].
>> >>>>  If
>> >>>>    no receive report is recieved within [[what timeout?]], the
>> >>>> algorithm
>> >>>>    will take action as if all packets in the interval have been lost.
>> >>>>    [[does that make sense?]]"
>> >>>>
>> >>>> The transmission of receiver reports is highly dependent on RTP
>> >>>> profile,
>> >>>> the RTCP bandwidth, trr-int parameter and any feedback events.
>> >>>>
>> >>>> If I start with assuming AVPF which seems reasonable in most browser
>> >>>> to
>> >>>> browser case with our current proposals for RTP support. Then if
>> >>>> there
>> >>>> are no feedback events the transmission of receiver reports will
>> >>>> occur
>> >>>> as often as the bandwidth allows, but no more often than the value of
>> >>>> trr-int parameter.
>> >>>>
>> >>>> Here is might be worth mentioning that I do expect trr-int to be set
>> >>>> to
>> >>>> avoid RTCP reporting to often due to the relatively high RTCP
>> >>>> bandwidth
>> >>>> values that will be set due to the multiplexing of audio and video in
>> >>>> a
>> >>>> single RTP session. Thus avoiding that RTCP rates are as high or
>> >>>> larger
>> >>>> than the audio streams they report in steady state.
>> >>>
>> >>> Agreed.  This is where my plans to suggest a baseline algorithm that
>> >>> melds
>> >>> the reception data of all the streams in the PeerConnection may be a
>> >>> significant advantage over doing bandwidth estimation on each stream
>> >>> independently.  We'll see if I can make the idea work, but there are
>> >>> some
>> >>> significant advantages if it does.  If not, we can estimate in each
>> >>> channel
>> >>> independently as per the Google algorithm.
>> >>>
>> >>> You can also use rtcp-fb PLI/etc events to hang these reports off of,
>> >>> increasing
>> >>> the frequency they get through with minimal extra bandwidth use.
>> >>>
>> >>>
>> >>>> When feedback events occur the stack will have the choice of sending
>> >>>> a
>> >>>> RTCP RR, that is a choice provided due to the reduced size RTCP
>> >>>> specification included. But if the loss cumulative count diff is
>> >>>> non-zero it might be worth mandating that the RR/SR is included in
>> >>>> any
>> >>>> such feedback RTCP packet.
>> >>>
>> >>> Exactly - or a TMMBR with the results of the receiver-side bandwidth
>> >>> calculations.
>> >>>
>> >>>> For that reason causing a feedback event when there is losses and
>> >>>> schedule them using the early algorithm may be a good choice to
>> >>>> ensure
>> >>>> timely reporting of any loss.
>> >>>>
>> >>>> If one uses AVP then the RTCP timing rules will give you when you
>> >>>> transmit RTCP feeedback and thus the parameterization becomes central
>> >>>> here. A clear issue is if people uses the minimal interval of 5
>> >>>> seconds
>> >>>> or the 360/Session_BW(in kbps). I would note that 5 seconds is very
>> >>>> long
>> >>>> in adaptation situations.
>> >>>
>> >>> Yes.
>> >
>> > In the proposed algorithm, the RTCP interval adds to the system response
>> > time. The response time governs the bandwidth increase rate so that the
>> > step
>> > into over-use will have a limited delay build-up before it can be
>> > detected
>> > and mitigated. Thus, a long RTCP interval results in a slow adaptation,
>> > but
>> > it should still be stable.
>> >
>>
>> I wonder how would you guarantee that such a long RTCP interval
>> doesn't result in instability when estimating bandwidth? Typically, a
>> delay-based CC algorithm can be vulnerable when timer become
>> inacurate. I suspect the delayed RTCP feedback can calculate available
>> bandwidth correctly. Why not use per-packet based feedback (using
>> AVPF, for example) in order not to cause any harm with this kind of
>> situation?
>
> I agree that more frequent feedback does improve the bandwidth estimation.
> No doubt about that.
>>


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?


Kind regards,
Soo-Hyun


>> I would think that a CC mechanism, at least, should be able to
>> calculate and suggest right/correct rate to the upper layer's codec so
>> that it could determine whether it actually increase/decrease encoding
>> rate or not, depending upon CC's suggested rate.
>>
>>
>> Kind regards,
>> Soo-Hyun
>
>
>
> --
> Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41
>
>