[Iccrg] Re: [Tmrg] convergence time

[Lachlan Andrew]

Greetings David,

On 28/10/2007, Xiaoliang (David) Wei <weixl at caltech.edu> wrote:
>     Another option, to eliminate the dependency to stability and
> timescale, is that we don't study the convergence of current rate.
> Instead, we study the convergence of the aggregate average rate. That is,
> if the instanenous rate of a flow at time t is x(t), we define the
> aggregate average rate of the flow at time t to be
> X(t) = 1/t * sum u=0->t x(u).
> ("sum" can be "integrate" if the time is continous).

Good idea.

> Then we study the convergence of the curve X(t) to the "final value".
> This process might be easier as:
> 1. X(t) is easier to measure because we can just look at the amount we
> have transfered from time 0 to time t;
> 2. X(t) converges even x(t) has a limit-cycle oscillation, so it is less
> sensitive to stability
> 3. If x(t) converges fast, X(t) converges fast too. We can still compare
> the convergence with X(t)
> 4. X(t) does have meaning in user-experience. It measures how long the
> users have to participate in the network to get to the desired rate.

They're all good points.

The main drawback is that  X(t)  converges (much) more slowly, since
it always gives some weight to the early rates.  If we want to observe
the impact of each of several newly arriving flows, we need to space
them out further if we use  X(t)  than we do if we use  x(t), or else
the transients will interact.

The time required to find the "final" value could already be quite
long, especially in the case of Reno, which takes hours to reach
equilibrium on large BDP paths.

What do others think?

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
http://netlab.caltech.edu/~lachlan