Oh, don't I wish.
Unfortunately, packets carrying CE bit set are just as likely to be lost due
to congestion as any other packet, so that the lack of ECN means EITHER
No congestion encountered, OR
So much congestion encountered that the routers are dropping packets with CE
bit set.
>From the PILC ERROR draft
(http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-00.txt) on page
9:
The problem with ECN is that the absence of packets marked as
"congestion encountered" should not be interpreted by ECN-capable
TCP connections as a green light for aggressive
retransmissions. On the contrary, during periods of extreme
network congestion routers may drop packets marked with explicit
notification because their buffers are exhausted - exactly the
wrong time for a host to begin retransmitting aggressively.
This isn't a criticism of ECN, which was never intended to be
used as a surrogate for explicit corruption notification - only
an explanation of why it isn't such a surrogate.
(some deleted stuff)
Recommendation: Implement ECN, but do not (mis)use it as a
surrogate for explicit corruption notification.
Gab Montenegro and I were REALLY bummed when we actually read the part of
the ECN spec that points this out...
Spencer
> -----Original Message-----
> From: Alex Cannara [SMTP:[email protected]]
> Sent: Friday, July 23, 1999 10:23 AM
> Cc: [email protected]; [email protected]
> Subject: Re: making satellite channel loss transparent
>
> 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.
>
> Alex
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:55 EST