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

[Randell Jesup <[e-mail]>]

On 9/20/2011 8:44 AM, Harald Alvestrand wrote:
> On 09/20/11 14:36, Soo-Hyun Choi wrote: 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?

I agree with Harald here; the entire algorithm doesn't need to run on 
the sender side alone.  An RFC can contain algorithms for calculating 
values (see RTCP jitter for an example), but I think here we want to 
make sure that the mechanisms we provide allow things to work when the 
implementations at the send and receive side are different.  For 
example, for the classic one-stream CC model like Google/GIPS's 
algorithm their use of TMMBR - it should work with anyone supporting 
TMMBR.  In our case we may find we need to add a new FB message, since 
the existing ones may not cover what we need to convey (and we probably 
don't want to go the RTCP APP route).  Or we may find it makes most 
sense to use a RTP header extension.  We'll see.


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

Agree (mostly) with Harald there, but I agree we don't want to specify 
the CC algorithm in total.  We may very well want to document a proposed 
baseline algorithm that meets the requirements we lay down in the spec, 
however.

-- 
Randell Jesup
[e-mail]