[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