Jamshid,
I agree, the use of some mechanism that makes a clear distinction
between loss and congestion available to the sender is what would make
things much better. I think others have also mentioned that loss and
congestion can become correlated in wireless links, due to how
contention can occur. This would mean that such links would need to
resolve the contention themselves (e.g., as does Ethernet), or provide
the proper info to the sender(s) so efficient transport-layer recoveries
are made.
Alex
Jamshid Mahdavi wrote:
>
> 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