Subject: RE: making satellite channel loss transparent

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 23 Jul 1999 11:50:23 -0500

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-masked]]
> Sent:	Friday, July 23, 1999 10:23 AM
> Cc:	[email-masked]; [email-masked]
> 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

---

From: Alex Cannara <[email-masked]>
Date: Fri, 23 Jul 1999 20:36:42 -0700

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