[Iccrg] LT-TCP followup

[Lachlan Andrew]

Greetings all,

Vijay Subramanian's email reminded me to remind the group of my
presentation to the ICCRG in February on what rate "should" be used
when there are corruption losses.

An incomplete write-up is available at
<http://netlab.caltech.edu/~lachlan/abstract/TCP_with_erasures.pdf>,
but the main points are as follows:

If flows experience non-corruption loss, we still want to allocate
rate "fairly".  In general multi-link networks, fairness cannot be
measured by seeing how far rates are from equal, and is better
measured using Kelly's utility maximisation framework.

The draft studies the (common) special case where the loss is on the
last link, such as when downloading data from a wireless hot-spot.  If
loss is high, we must distinguish between fairness of send rates and
of receive rates.  We claim that fairness should be of receive rates,
but that send rates should be used when calculating the level of
congestion in the network.  In this framework:

- If we aim to get maximum throughput (ignoring fairness), the only
flows which should transmit are those which have the minimum loss.
- If we aim to get max-min fairness, the send rate should scale up as
1/(1-e)  where  e  is the erasure rate (that is, retransmissions don't
count at all as part of our "fair rate")
- If we want proportional fairness (as FAST implements) we should send
at the *same* rate regardless of how much loss there is on the last
hop.
******
- If we want the same fairness that TCP-friendliness implies (which
corresponds to "alpha=2" in Mo and Walrand's terminology and which I
think is what LT-TCP wants) then we should actually send at a slightly
*higher* rate (by a factor of 1/sqrt(1-e)) when there is loss than
when there is no loss.
******

Agreement or disagreement would be welcome.

The above draft doesn't consider the implementation at all.  I'd
encourage the LT-TCP designers to think about whether LT-TCP
can/should be modified to use this "fair" rate, and I'd be happy to
discuss it either on- or off-list.

Cheers,
Lachlan

On 02/08/07, Vijay Subramanian <subrav at rpi.edu> wrote:
>
> At the end of the ICCRG meeting in Chicago , Wesley Eddy suggested that we
> provide some input on how LT-TCP, our enhancements to TCP, can help in solving
> some of the open research issues that are being currently addressed in the
> ICCRG.
>
> Challenge 3.3: Corruption Loss
> The draft poses the challenges: How should corruption be detected and what
> should be the response?
>
> ... In particular, under no-loss conditions,
> LT-TCP introduces no overhead and the behavior is identical to that of
> TCP-SACK.

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603