[Iccrg] LT-TCP followup

[RAMAKRISHNAN, KADANGODE K (K. K.)]

We are very appreciative of the support for LT-TCP from the
group. Thank you. 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. The criteria suggested by Lachlan that the fairness
should be based on the received goodput emphasizes that a flow
experiencing loss deserves a larger share of the bandwidth than
other flows through the rest of the network, because the utility as
perceived by the receiver (and hence the application) is the primary
measure of interest. Although we may agree that the utility as
perceived by the application is what ultimately matters in an
egalitarian world, we have been more restrained in our approach. This
is driven by the need to have our protocol enhancements be widely
applicable, where the bottleneck link for a flow may not be the
wireless hop and there may be one or more wireless hops that are
anywhere in the path. As a consequence, 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. The question that has come up is that under loss, TCP
(e.g., SACK) may not get as high a throughput as LT-TCP when both
flow through a lossy link. 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.  When TCP builds up its
demand (e.g., after a transient loss event), LT-TCP continues to
remain "TCP-friendly".

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. The difference is in what we send
within that window.  As a result, the fairness achieved is the same as
TCP.  The load of this flow going over a lossy wireless path is no
different from another flow that is not going over the wireless
path. The load shares on the non-wireless paths therefore do not
change from TCP, which we believe is important. At the same time,
within that share for the flow, we attempt to maximize the utility for
the flow in the presence of losses. We size the amount of loss
tolerance to get the optimal goodput for the flow, without it
adversely impacting other flows. With the combination of link layer
enhancements (Hybrid ARQ), we can also strike a balance between
goodput and end-end delay.  This is why we determine how much FEC to
add, and to balance that FEC based on a proactive size of FEC based on
the loss observed, and a reactive FEC based on the short-term feedback
of SACK.

3) We do not add overhead when there is no loss. Therefore, there is
no "deadweight" overhead when the flow goes over a lossless path. As
such, the LT-TCP enhancements to TCP can be general and used always. 
It does not have to be "turned on" once we determine we are on
a wireless path or any such method.

4) We use ECN to disambiguate between congestion and packet corruption
or erasure. We realize that it has taken 20 years for ECN to get where
it has, and it may take a while longer before it gets ubiquitously used
:-). 
So, we do make sure that if the environment does not have ECN in the
end-end
path, then we will turn off the use of LT-TCP, so that we have the
reaction to loss due to congestion as used by traditional TCP. If
there is another, more direct, indicator of packet corruption, we are
happy to use it and we think our mechanisms will work just as well.


Thank you very much,
   K. K. Ramakrishnan, Shiv Kalyanaraman and Vijay Subramanian.
----
K. K. Ramakrishnan                  Email: kkrama at research.att.com
AT&T Labs-Research, Rm. A117        Tel: (973)360-8764
180 Park Ave, Florham Park, NJ 07932    Fax: (973) 360-8871
      URL: http://www.research.att.com/info/kkrama