Spencer, yes I wasn't suggesting ECN as "the defined standard", and
wasn't even aware of all the problems with it you mention. I'm just
hoping for something accurate to be done regarding distinguishing error
and congestion loss, since the former often lasts 24 hours a day, when
it happens due to hardware, not just during busy periods.
Alex
Spencer Dawkins wrote:
>
> 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