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

Harald Alvestrand harald at alvestrand.no
Fri Mar 30 10:33:11 CEST 2012


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

The current draft proposes that we're OK with a reaction time of around 
10 seconds for a mechanism that we expect to use only in "emergencies" 
(such as total channel failure) - on the basis that getting a faster 
reaction time would require too much redesign of other parts of the 
ecosystem.

As long as we can assume we get feedback signals in a timely fashion, we 
can take the absence of signals as a sign for "continue as usual", so 
the "emergency brake" is something we need when we have a total 
breakdown of the feedback channel, not for "day-to-day control".

I think a discussion on what the timing requirements for an emergency 
brake are is a Good thing - but it may belong on AVTCORE rather than here.




More information about the Rtp-congestion mailing list