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 05:46 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 655C021F8B0F for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 22:46:37 -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 n6mVvNUzOwrk for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 22:46:36 -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 45A5F21F8B0D for <rtcweb@ietf.org>; Mon, 19 Sep 2011 22:46:36 -0700 (PDT)
Received: by fxd18 with SMTP id 18so198589fxd.31 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 22:48:59 -0700 (PDT)
Received: by 10.223.45.85 with SMTP id d21mr699356faf.63.1316497738952; Mon, 19 Sep 2011 22:48:58 -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 b21sm446928fab.8.2011.09.19.22.48.57 (version=SSLv3 cipher=OTHER); Mon, 19 Sep 2011 22:48:57 -0700 (PDT)
Received: by bkaq10 with SMTP id q10so167260bka.31 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 22:48:55 -0700 (PDT)
Received: by 10.204.133.138 with SMTP id f10mr212626bkt.379.1316497735840; Mon, 19 Sep 2011 22:48:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.205.81.10 with HTTP; Mon, 19 Sep 2011 22:37:43 -0700 (PDT)
In-Reply-To: <CAOhzyf=MqsgsGUi521oJ5N6+T+K1N01MjeHYPpX_VZK8uyQksw@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>
From: Soo-Hyun Choi <soohyun.choi@cl.cam.ac.uk>
Date: Tue, 20 Sep 2011 14:37:43 +0900
Message-ID: <CAKkvrEkx0mqnDWqNYse3r9WUMbYKNZhrBqQ0SPUAnTtKrA5bLg@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 05:46:37 -0000

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 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