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

On 09/20/2011 05:44 AM, Harald Alvestrand wrote:
> On 09/20/11 14:36, Soo-Hyun Choi wrote:
>> Harald,
>>
>> On Tue, Sep 20, 2011 at 20:47, Harald 
>> Alvestrand<harald@alvestrand.no>  wrote:
>>> let's avoid unquantifiable terms in our discussions. "A little more 
>>> careful"
>>> is an unquantifiable term.
>>>
>>> If we want to say "I think the algorithm must guarantee that the 
>>> bandwidth
>>> estimate is updated within 1.5 seconds when the available bandwidth 
>>> changes
>>> from 2 Mbit/sec to 1 Mbit/sec", let's say something like that - 
>>> focus on
>>> what the requirements are.
>>>
>>> We can always be a little more careful. But it doesn't tell us when 
>>> we're
>>> close enough.
>>>
>> Sorry if my previous email looked that way to you (of course, I didn't
>> mean to just pray for the mere hope). I was talking about some general
>> CC principles in the high level for real-time interactive multimedia
>> applications, like some of us did too in this thread.
> Sorry, not intended to point at anyone in particular - I have been 
> worried about several conversations that seemed to be straying very 
> far from the "brass tacks" here.
>> 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?

In the context of RTCWEB, I have constrained the meaning of quick to an 
ICE path. Or, any information known *before* the duration of any session 
is "quick", yet that does not include any actual connection delay.

>>
>>> 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.
>>
>> So, my original question/suggestion was why not use AVPF (which is
>> smaller packet than the standard RTCP) to generate/report more
>> frequently to the sender in your algorithm. Or alternatively, I have
>> already designed a window-version's of TFRC that re-introduces a
>> TCP-like Ack-clocking, so-called TFWC (TCP-Friendly Window-based CC),
>> which performs reasonably well (as good as TFRC) for the similar
>> situations (RTC environment).
>>
>> 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.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

-- 

---
<i>The wheel.</i metro-link=t dzonatasolyndra>