MIME-Version: 1.0
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)
Precedence: list

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
>> >>>> =A0 =A0sender, which will happen [[how often do we expect? and why?=
]].
>> >>>> =A0If
>> >>>> =A0 =A0no receive report is recieved within [[what timeout?]], the
>> >>>> algorithm
>> >>>> =A0 =A0will take action as if all packets in the interval have been=
 lost.
>> >>>> =A0 =A0[[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 browse=
r
>> >>>> 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 se=
t
>> >>>> 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. =A0This is where my plans to suggest a baseline algorithm th=
at
>> >>> melds
>> >>> the reception data of all the streams in the PeerConnection may be a
>> >>> significant advantage over doing bandwidth estimation on each stream
>> >>> independently. =A0We'll see if I can make the idea work, but there a=
re
>> >>> some
>> >>> significant advantages if it does. =A0If not, we can estimate in eac=
h
>> >>> 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 sendin=
g
>> >>>> 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 centr=
al
>> >>>> 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 respon=
se
>> > time. The response time governs the bandwidth increase rate so that th=
e
>> > 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=A0|=A0WebRTC Software Eng=A0|=A0hlundin@google.com=A0|=A0+4=
6 70 646 13 41
>
>