Jon.Crowcroft at cl.cam.ac.uk
Tue Apr 2 22:55:30 PST 2002
the timescales for distributing congestion can be relatively fast,
since if ecn++ signals are generated by virtual queues, they are
already time averages....
the routing system should damp _decisions_ made on the basis of suc=h
signals- 5 mins might be a bit long - it wil ldepend on the actual
rate of change of number of flows on various paths....
something else we need to estimate (there are various ways to estimate
flow count at any given time...it doesnt have to be that accurate- we
want to know if the rate of change of load is significant and start to
think about using ecn++signals as a route change metric when it is
In message <1017815741.2058.6.camel at lap10-c703>, Michael Welzl typed:
>>> David P. Reed wrote:
>>> > At 11:21 AM 4/2/2002 +0100, Jon Crowcroft wrote:
>>> >> ok - here is a practical proposal
>>> >> called ECN++ (or whatever)
>>> > I like some of this, but it's way too complicated in a way that doesn't
>>> > seem likely to scale well.
>>> > The key elements - capturing a "early congestion event" early at the
>>> > bottleneck, and then delivering it back to a "congestion manager" -
>>> > seems to make sense.
>>> > But here's an alternative model. Build a "congestion sampler" overlay
>>> > network.
>>I like that idea a lot!
>>> Some general questions that I had when reading this thread:
>>> (1) How static is congestion? Seconds, minutes, days? How long would
>>> such a mechanism take to stabilize?
>>That's a difficult one. Internet bandwidth is self similar; therefore,
>>I would assume that based on measurements during no matter which
>>interval, it should be possible to give feasible feedback for a
>>specific (the same?) interval.
>>In other words, I guess that a 5 minute's average bandwidth would
>>yield the most sensible estimate for an application which is interested
>>in the average bandwidth during the next 5 minutes. But that's just
More information about the end2end-interest