[Iccrg] Updated draft

[[e-mail] (Murari Sridharan)]

We updated the draft based on input from Lachlan (Thanks). The draft is available at http://www.ietf.org/internet-drafts/draft-sridharan-tcpm-ctcp-01.txt

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071030/0b258bdf/attachment.html
>From [e-mail]  Wed Oct 31 17:18:13 2007
From: [e-mail] (Lachlan Andrew)
Date: Wed Oct 31 17:18:00 2007
Subject: [Iccrg] Re: [Tmrg] convergence time
In-Reply-To: <Pine.GSO.4.58.0710282328230.23481@inky>
References: <[e-mail]>
	<Pine.GSO.4.58.0710282328230.23481@inky>
Message-ID: <[e-mail]>

Greetings David,

On 28/10/2007, Xiaoliang (David) Wei <[e-mail]> 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: [phone]    Fax: [phone]
http://netlab.caltech.edu/~lachlan