[Iccrg] LT-TCP followup

[Michael Welzl]

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