[Iccrg] LT-TCP followup

[Lachlan Andrew]

Greetings KK,

On 03/08/07, RAMAKRISHNAN, KADANGODE K (K. K.) <kkrama at research.att.com> wrote:
> We are very appreciative of the support for LT-TCP from the
> group. Thank you.

Yes, I hope it gets standardised.

> Here are a few points, in response to both Lachlan and Michael's emails.
>
> 1) In response to Lachlan Andrew's email, we realize that the fairness
> criterion may be up to debate. In LT-TCP, we have been trying to not
> pick a new one, and remain within the constraints that the Internet and
> TCP operate under.
[deleted]
> We continue to remain within
> the current TCP framework of sending as many bytes into the network
> as the window would allow, with the window dynamics remaining
> strictly in accordance with current TCP flow and congestion avoidance
> mechanisms.

My understanding is that you don't respond to lost packets.  That
seems very far from following the "letter of the law" of TCP.  If you
say that you are following the "spirit" of the law (which I agree you
are), then I would suggest that the spirit of the law is about how
much data that is transported.  If the FEC were done at a layer below
TCP (where IMHO it belongs), then it wouldn't be included as part of
the application rate.  Why should it be included now?

> We would like to emphasize that LT-TCP's
> advantage is only that it may use the residual capacity that is left
> un-utilized by TCP-SACK in such environments.

I've heard that argument used before (for HS-TCP etc), but never
really understood it.  How do you measure how much capacity TCP-SACK
can't use?  If SACK has a small enough RTT, then even at high loss
rates it will get almost full link utilisation.  What does LT-TCP do
then?

My understanding is that a flow which sends fast enough to induce
congestion losses will always slow down a competing flow which
responds to losses.

> 2) In response to Michael's (and thereby Sally's concern): we do not
> want to send, or keep sending, at a high rate, to overcome loss. We
> only send as much as the traditional TCP window flow and congestion
> avoidance mechanisms will allow.

Isn't the main difference that you don't consider packet erasures when
implementing the congestion avoidance mechanism?  I strongly agree
that is a  Good Thing  to do, but I don't think you can argue that
you're not *fundamentally* changing the mechanism.

If we're fundamentally changing the mechanism, I think we should work
out what we "should" do, rather than what changes the fewest "lines of
code" in the specifications...  We don't want to be overly constrained
by an   appearance   of backward compatibility.

Once again, LT-TCP does what I'd argue is "right for proportional
fairness", so perhaps we're just disagreeing about terminology, and I
should take back the suggestion of changing LT-TCP :)

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