[Iccrg] LT-TCP followup

[Shivkumar Kalyanaraman]

Michael,

We used ECN as an unambiguous indication of congestion so that we could
disambiguate that from packet corruption. ECN has been in the standards
process and has been making steady progress both in the IETF standards
track and vendor implementation. This motivated our use of ECN. However,
if ETEN unambiguously signals corruption (instead of ECN), we could use
that approach as well. We would be happy to use whichever mechanism is
widely available and the group suggests that we use that. LT-TCP would
(we strongly believe) work equally well with either approach.

If ECN is used, the likelihood of congestion related loss may be
minimized. However, if there is congestion related loss, because either
ECN is absent, or there are also end-systems that do not respond to ECN,
then LT-TCP will have a robust method for safely reverting back to
TCP-SACK behavior. When there is loss that is caused due to congestion
on the path (and ECN signals are absent), LT-TCP will revert back to
TCP-SACK.


best
-Shiv
===
Shivkumar Kalyanaraman
Professor, Dept of ECSE, Rensselaer Polytechnic Institute (RPI)
110, 8th Street, Room JEC 6003, Troy NY 12180-3590
Ph: 518 276 8979   Fax: 518 276 4403
WWW: http://www.ecse.rpi.edu/Homepages/shivkuma
Google: "Shiv RPI"


On Mon, 6 Aug 2007, Michael Welzl wrote:

> Hi,
>
> While, as you know, I'm a fan of the LT-TCP idea, this:
>
> > 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.
>
> ...is unacceptable in my opinion. It's okay as a theoretical
> exercise, but I wouldn't want to see a practical solution
> assume that only ECN signals congestion, and packet loss
> doesn't.
>
> As I mentioned before, the right thing to do would be to flip
> it around, and *only* assume that there was corruption when you
> have a reliable signal saying so. Otherwise, in the presence of
> packet loss (which can always be due to an overflowing queue,
> ECN notwithstanding), the right thing to do is to assume congestion.
>
> Examples of such signals include the data checksum option in
> DCCP, and ETEN:  http://www.ir.bbn.com/projects/pace/eten/
> ... and (sorry for repeating myself) ETEN+LT-TCP would be a
> real winner in my opinion.
>
> Cheers,
> Michael
>
>
>
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>