[Iccrg] LT-TCP followup

[Vijay Subramanian]

Hi folks,


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. To this end, we look at 3 challenges outlined in the draft and discuss
how these can be impacted by our work.

Following are some notes regarding how LT-TCP can contribute to solving the open 
research issues
outlined in M. Welzl, D. Papadimitriou, M. Scharf, "Open Research Issues in
Internet Congestion Control". The draft can be found at
http://www.ietf.org/internet-drafts/draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt


Section 3.2: Dynamic Range of Requirements:
The draft notes that TCP is required to operate under a wide variety of
scenarios and dynamically changing conditions. We note that TCP is designed for
low end-to-end loss rates. For example, even robust variants such as TCP-SACK
are unable to perform well for packet loss rates above 5%. As wireless networks
become ubiquitous, we expect to see an increase in the end-end loss rate
especially as cell sizes get smaller and accommodate higher data rates. An
enhancement of TCP is needed to enable it to be robust to higher loss rates and
we believe LT-TCP fills this gap.

Challenge 3.3: Corruption Loss
The draft poses the challenges: How should corruption be detected and what
should be the response?  LT-TCP solves this problem by making use of Explicit
Congestion Notification (ECN). The draft by Welzl et. al. discusses possible
feedback options of which ECN is one (and the simplest). In an ECN environment,
LT-TCP assumes packet loss is caused by corruption and ECN signals are assumed
to be the primary indicators of congestion.  Of course, if ECN is not supported
in the end-end path, LT-TCP can fallback to TCP-SACK behavior.


The additional question of how to react to corruption is addressed by noting
that techniques of error and erasure correction have proven to be efficient in
dealing with losses at PHY/MAC layers. We naturally extend TCP-SACK with
Forward Error Correction (FEC) to cope with high losses. But unlike the PHY/MAC
layer solutions, our design of LT-TCP adopts FEC at the granularity of packet.
The FEC is designed to be adaptive and scales according to the estimated loss
rate, and is partitioned into a proactive (based on medium-term loss rate
estimation) and reactive (based on the short-term measure of loss). Information
already available in SACK blocks can be used to tune the FEC and minimize
overhead.  By seamlessly enhancing TCP-SACK with FEC, we can not only provide
protection against high losses but do so with minimal overhead and changes to
the existing TCP framework.  The overhead of error protection introduced by
LT-TCP scales with the loss rate. In particular, under no-loss conditions,
LT-TCP introduces no overhead and the behavior is identical to that of
TCP-SACK.

Challenge: Impact on Latency: Challenge 7 talks about the requirements of
elastic traffic.  Interactive applications have delay constraints. Clearly, as
the loss rate increases, increased retransmissions and higher link layer
latencies (due to these retransmissions) will increase the time taken to
deliver a packet to the receiving application.

LT-TCP minimizes latency through the use of FEC, to proactively protect against
packet erasures in a lossy environment.  Since FEC packets can be used to
recover lost data packets, retransmissions of data packets (as in current TCP
variants) can be complemented with FEC packets under these conditions.  A
sufficient subset of the FEC block can be used to recover the original data
packets. This has the potential to significant reduce the in data transfer time
in lossy environments, compared to retransmission driven recovery techniques.
LT-TCP adds virtually no additional delay in a loss-free environment.

Any feedback or suggestions are highly appreciated.

Thanks,

Vijay Subramanian


Networks Lab, RPI :
Phone: 518-276-8289
http://poisson.ecse.rpi.edu/~vijay