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

Randell Jesup randell-ietf at jesup.org
Sat Apr 7 19:19:57 CEST 2012


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"

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


-- 
Randell Jesup
randell-ietf at jesup.org


More information about the Rtp-congestion mailing list