On Mon, Apr 2, 2012 at 7:44 AM, Michael Welzl
<michawe@ifi.uio.no> wrote:
Argh, yes, I guess this one letter was the cause of a misunderstanding... Thanks!
Sent from my iPod
On Apr 1, 2012, at 23:56, Lachlan Andrew <lachlan.andrew@gmail.com> wrote:
Greetings Michael,
Are you saying you need an emergency "brake" (i.e., slowing down)
rather than emergency "break" (i.e., termination, with or without a
restart later)?
Cheers,
Lachlan
On 30 March 2012 21:17, Michael Welzl <
michawe@ifi.uio.no> 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.
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).
Cheers,
Michael
--
Lachlan Andrew Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew>
Ph +61 3 9214 4837