[Iccrg] Proposal for ICCRG operations

[Lachlan Andrew]

Greetings all,

On 03 Feb 2006 09:32:27 +0100, Michael Welzl <michael.welzl at uibk.ac.at> wrote:
> So, the index should contain:
>
> * normalized throughput
> * loss
> * fairness (let's use the Jain Fairness Index)
>
> It could then look something like this:
>
> WI = (T*t + L*l + F*f) / 3
>
> where WI is "Welzl Index" (tm)   ;-)
> T is normalized throughput
> L is normalized loss
> F is the Jain fairness index (which is already a value
> in the 0..1 range)

A good way to summarise throughput and fairness is just to take the
*harmonic* mean of the flows' throughputs instead of the arithmetic
mean (or equivalently, the aggregate througput).  That corresponds to
measuring the mean time to transfer a given number of bytes, which is
the quantity actually observed by an application.

This metric avoids the arbitraryness both of using a sum or product,
with the problem of  selecting weightings, and also of Jain's index. 
(If one flow out of many is starved, Jain's index can still report
high "fairness", but the harmonic mean of rates goes to zero
highlighting the problem.)  Similarly, if one flow (or protocol) is
unable to achieve a high rate, Jain's index says it is "unfair" for
another to out-perfom it.  The harmonic mean correctly indicates that
rates  0.5 and 1  are better than rates 0.5 and 0.5 (but less good
than 0.75 and 0.75).

(Trying to maximise the harmonic mean of the rates is just a special
case of "utility maximisation", using  alpha=2 in Mo and Walrand's
alpha-fairness framework.  It could be argued that this utility
function is itself arbitrary, but it seems less so than summing
thoughput and "fairness".)

Combining throughput and fairness of throughput can be done
systematically, since they both just reflect the average rates.  A
bigger challenge is incorporating loss/delay and the other metrics
Wesley Eddy mentioned (stability, convergence time etc).  For file
transfers, it could be argued that these only matter insofar as they
affect the total transfer times.  This applies to both long- and
short-lived flows (but not to real-time flows).  However, there is
still a problem of how to weight the times:  The transfer time of each
short flow should get less weight than a long flow, but weighting them
in proportion to the amount of data may put too little weight on them.

Cheers,
Lachlan

--
Lachlan Andrew  Dept of Computer Science, Caltech
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603