[Iccrg] LT-TCP followup

[Lachlan Andrew]

Greetings Michael,

Thanks for your reply.

On 02/08/07, Michael Welzl <michael.welzl at uibk.ac.at> wrote:
>
> 5 In Marina Del Rey (and a preceding email), Lachlan presented
>   his theory which contradicts the intuition in item #3 above.
>   Could it be that you *only* consider a wireless link, not
>   the rest of the path? That could be a reason for your idea
>   of actually increasing the rate to make sense in your setup,
>   but not in practice

No, we consider the whole path.  The assumption is just that that the
wireless link is the *last* hop.  I agree that this doesn't consider
the problem of uploading from a wireless link (which is still
work-in-progress), but it certainly covers a very large fraction of
the current cases.

I was deliberately trying to make it sound counter-intuitive.  If it
is phrased as "the application should send  slower  by a factor of
(1-e)^{1/2}", does that make it sound more acceptable?  The key to
remember is that the rate   received   (for LT-TCP, that is the rate
before FEC encoding) is less that the rate   sent   (i.e., the rate
after FEC encoding).  I agree that the former should go down, but
there is a case for the latter to go up.  This is in keeping with what
John Leslie  proposed:

On 09/09/06, John Leslie <john at jlc.net> wrote:
> Michael Welzl <michael.welzl at uibk.ac.at> wrote:
> > The correct reaction to corruption.
>
>    Actually, there is one: increase the reundancy of coding.
>
>    This actually will result in a hopefully-slight _increase_ in bandwidth
> demand. This is _not_ wrong!

What my calculations do is show that (a) for max-min or "TCP-friendly"
fairness, John is right that the bandwidth demand goes up, (b) For
proportional fairness, TCP-HACK, FAST and LT-TCP are right that the
bandwidth demand should be unchanged (with the increased redundancy,
as FEC or retransmissions, lowering the payload rate).

When I suggested changing LT-TCP, that was just removing the
incongruity that LT-TCP aims to be TCP-friendly, and so it would be
sensible for it to have response (a).

> 6 K K Ramakrishnan presented LT-TCP in Marina Del Rey too,
>   and now there's this follow-up. Given the unknown *rate*
>   response to corruption, in my very personal opinion,
>   this seems to be the first acceptable proposal

I agree that LT-TCP is the first practical proposal, as a way to
implement the control.

However, as you say Michael, it doesn't address the problem of the
"unknown *rate* response".  My guess is that it includes the FEC
overhead as part of the allowed rate, and causes the application to
send at reduced rate  (1-e)  where  e  is the bit erasure probability.
 At the level of abstraction used in my model, that is the same as
"ignoring the loss in calculating the sending rate", which (when all
of the loss is on the last hop) gives proportional fairness.

LT-TCP answers the application's question "*How* do I send at a lower
rate when my link has errors", but not "*Why* do I send at a lower
rate, by a factor of (1-e)?  Why not (1-e)^2?  Why not (1-e)^{1/2}?"

I'm not sure what specific part of our/John Leslie's proposal you
don't find acceptable, but if you tell me then I'll gladly do what I
can to fix it :)

Cheers,
Lachlan

-- 
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