Alex Cannara <[email protected]> writes:
> This is an issue that would be helped by good ECN and new sender code,
> if the sender then could assume lack of ECN implies error loss -- thus
> keep sending with no backoff. In simple loss cases on normal WANs, <1%
> loss gives >20% slowdown in typical, current TCP throughput.
Unfortunately, you can't make this assumption ("lack of ECN implies
error loss").
I believe that Phil Karn (I hope I'm attributing this correctly) has
suggested something like an "ICMP Corruption" message which a router
could send back if a packet failed a link layer CRC error. Kevin just
explained this to me yesterday, and I think it sounds like a
reasonable idea (provided you could get it implemented in the routers
-- but it would only need to be implemented in hosts/routers which
were connected to high error links, so maybe it would be OK). If
something like this were implemented, then the sender could be *sure*
that the loss was not due to congestion.
Note that this doesn't have the problem of the ICMP Source Quench,
which is that you generate *more traffic* in response to congestion.
Note that there is one danger with this: misunderstanding. For
example, consider an ATM AAL5 packet which arrives with one cell
missing. The people writing the code need to recognize that this is a
result of *congestion*, not corruption. I could easily imagine
someone getting this wrong.
I don't know enough about wireless to know if there are similar
situations where apparent corruption can actually be caused by
congestion conditions (which then ought to warrant a TCP backoff).
--J
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:55 EST