[Iccrg] LT-TCP followup

[Michael Welzl]

>Various TCP variants today track rtts, which would allow differentiation
between corruption loss and overflow loss. >Obviously, in a extremely worst
case scenario, a packet loss overflow could occur at a single packet with no
"rtt >evidence" (rtt increase) on "surrounding" packets of a TCP stream. But
IMHO most of the scenarios I've seen, the rtt >increase evidence is there.

i know, and I think I didn't say anything to discourage using other
implicit feedback too; this being said, rtt increase is misleading too,
how do you distinguish a growing queue from link layer arq happening
because of corruption?


>Notice that mistakenly taken a corruption loss as overflow loss does not
necessarily have to have a big impact on a TCP >session. It is bad enough
for VJ (alpha=2) TCP, but other controllers can be much more "immune" to
sporadic "misreading" >of packet loss information.

ok, i can imagine that

cheers
michael