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

[Harald Alvestrand <[e-mail]>]

On 09/21/2011 09:59 AM, Soo-Hyun Choi wrote:
> Harald,
>
>>> 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?
> Sure - one may not need to send the receiver report every so often
> when network is stable. But the question is "how long stable is
> stable?". Perhaps, the definition of "stable" might fall into
> unquantifiable term, too? Anyway, when I said "quickly", I meant "at
> least once in an every RTT" (borrowing from the TCP SACK analogy), in
> which the use of the standard RTCP RR is not suitable in this level of
> granularity.
I think receiver->sender reporting every RTT (or every packet, which is 
frequently less frequent) is overkill, but that's a statement with a lot 
of gut feeling and very few numbers behind it.

One advantage we have in RTCWEB is that we can assume that if audio and 
video work OK across the network, we're in a good place. We don't have 
to worry about getting gigabyte file transfers to utilize 90% of the 
link - even thogh we have to worry about audio and video functioning 
while those gigabyte transfers are taking place.
>>> 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.
>>
> Question: Isn't your draft also proposing a new CC mechanism in the
> context of RTCWEB?
No, to quote from the draft:

    It is published to aid the discussion on mandatory-to-implement flow
    control for RTCWEB applications; initial discussion is expected in
    the RTCWEB WG's mailing list.

It's describing an algorithm that already exists outside of the IETF. It 
seems to have succeeded in stimulating the discussion.
If the conclusion of the discussion is that something along these lines 
should be standardized, I hope the ADs and chairs of the IETF can give 
us guidance on where the discussion of this standardization should take 
place.