[R-C] Timely reaction time (Re: Comments on draft-alvestrand-rtcweb-congestion-01)

Michael Welzl michawe at ifi.uio.no
Sat Apr 7 19:37:12 CEST 2012


On Apr 7, 2012, at 7:19 PM, Randell Jesup wrote:

> On 3/30/2012 6:17 AM, Michael Welzl wrote:
>> On Mar 30, 2012, at 10:33 AM, Harald Alvestrand wrote:
>>> On 03/29/2012 01:55 PM, Michael Welzl wrote:
>>>>> Section 4: par 3, "This algorithm is run every time a receive  
>>>>> report
>>>>> arrives..." => so in case of severe congestion, when nothing else
>>>>> arrives, this algorithm waits for 2 * t_max_fb_interval... so  
>>>>> can we
>>>>> rely on the mechanism to react to this congestion after roughly an
>>>>> RTO or not? (sounds like not) Is that bad? (I guess)
>>>>>
>>>>> There is a need for some emergency break mechanism if no feedback
>>>>> gets through.
>
> Per discussion, "emergency brake"

yep (sorry for that)


>>>> I totally agree - what I meant is, it isn't clear to me if that
>>>> emergency break is activated in time or too late. It should be in
>>>> time (i.e. after roughly an RTO).
>>> This seems to be a subject that should be discussed in the context  
>>> of
>>> the circuit-breakers draft: What kind of response time is  
>>> appropriate
>>> for such a mechanism, and why?
>>
>> I think not: we're talking about two kinds of situations here. The
>> context here is: there was congestion, we should react to it within  
>> an
>> RTO (and have an "emergency break" to always do that - but maybe that
>> term was misleading). The circuit-breakers draft is about a much more
>> serious condition (such as persistent congestion), warranting a much
>> more serious reaction (terminating the connection).
>
> What's the RTO in this case, since we're talking UDP media streams?   
> TCP RTO?

Something in the order of that is what I had in mind. An RTT is the  
control interval that we can and should act upon, and of course you'd  
rather have an estimate that is averaged, and you really want to avoid  
having false positives from outliers, so you want to give it a  
reasonable safety margin. The TCP RTO has all that.

Note I'm not "religious" about this - I think a mechanism that would  
react e.g. an RTT late could still lead to a globally "okay" behavior  
(but that would then be worth a closer investigation). My main point  
is that it should be around an RTO, or maybe a bit more, but not  
completely detached from RTT measurements.

Cheers,
Michael



More information about the Rtp-congestion mailing list