[Iccrg] LT-TCP followup

Sat Aug 4 15:14:59 BST 2007

Hello Lachlan,
Thank you for your note.
My responses appear below, in-line.

-----Original Message-----
From: Lachlan Andrew [mailto:lachlan.andrew at gmail.com] 
Sent: Friday, August 03, 2007 4:48 PM
To: RAMAKRISHNAN, KADANGODE K (K. K.)
Cc: Michael Welzl; iccrg at cs.ucl.ac.uk; David Hayes; Vijay Subramanian;
Shivkumar Kalyanaraman
Subject: Re: [Iccrg] LT-TCP followup

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. 

KK> This is not quite correct. Let me clarify what we do. We respond to
congestion, in the same way that TCP does and we depend on ECN for
congestion indications. So, to that extent, we are following the "letter
of the law" for TCP. If ECN exists in the end-end path and works as it
is intended to, then "lost packets" would be primarily due to corruption
and not congestion. In the past, the design of TCP has intricately tied
together the reliability and congestion components together, with the
strong assumption that packet loss implied congestion. It was
by-and-large true then, because we didn't have as much wireless as we
have today or might have in the future. So, if the intent and "law" of
TCP is to respond to congestion, then we try to remain within those
boundaries.

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?

KK> We agree with you that ultimately application performance should be
the main criterion. But from a resource perspective each individual
entity (e.g., flow) that qualifies to be treated distinctly, may be
viewed as getting an equal share (e.g., when max-min is the criterion
for fairness). Then, the total load (data, headers, other "stuff" like
FEC) all get bundled into the share that the entity is eligible for.
There are multiple fairness goals, and that is why we have discussions
about what is the right thing to do.

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

KK> We do not measure the capacity that a competing TCP-SACK flow does
not use. If the channel is idled because TCP-SACK suffers a timeout, it
is only then that LT-TCP would be able to utilize that bandwidth. In the
case that there is a small enough RTT and SACK is good enough even under
the high loss rate to NOT experience a timeout, then TCP-SACK and LT-TCP
would use that link fairly. That was our intent when we showed a few
slides in the February ICCRG meeting on LT-TCP being fair and achieving
the same window/throughput as TCP-SACK. 

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.

KK> If a flow induces congestion - period - and responds to ECN, then it
will not slow down a competing flow that also responds to congestion
indication. The issue, which you raise is: what happens when loss is the
primary source of congestion indication. This is where we need to
separate the two: congestion indication, and lossy channels. We used ECN
to disambiguate them. If there is another way to disambiguate the two,
we'd definitely consider it. So, we want to make sure we make it clear.
LT-TCP does not ignore congestion and keep sending. It does everything
we all have come to understand is needed up to now about congestion
avoidance.

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

KK> We are glad you say it is a good thing to do. The main issue is
whether we are changing the mechanism, and what is "the mechanism"? If
loss as being the sole indication of congestion is the dominant part of
"the mechanism", yes we are diverging from that. But if the congestion
avoidance algorithms that include the increase/decrease, timeout (when
the end-system believes that the channel is severely congested) etc.,
are "the mechanism", we have tried not to change these. 

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.
KK> We certainly sympathize with the view that we should explore what
the "right thing to do" should be. We are ready to take input and vector
the design of LT-TCP towards the consensus view of what that is. The
difficulty is that there may be many views of that goal. From our
perspective, we wanted to see how well a sensibly put together set of
components for loss-tolerance (as distinct from congestion control and
avoidance) could be put together and work well with the existing TCP
congestion control functions. And we wanted to demonstrate how the
intricately-tied-together functionality of reliability and congestion
avoidance could be teased apart. And honestly, we have tried to retain
backward compatibility, not just appear to be backwards compatible.
Which is why we say that LT-TCP would switch back to TCP-SACK in the
absence of ECN as a congestion indication, rather than trying to invent
something else.

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
KK> Thanks for your input and I hope this clarifies a bit more of what
we've done and why...
-- 
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