Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!ames!sdcsvax!ucbvax!gateway.mitre.ORG!tsuchiya
From: tsuchiya@gateway.mitre.ORG (Paul Tsuchiya)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: ISO8473 vs. IP
Message-ID: <8709091233.AA01229@gateway.mitre.org>
Date: Wed, 9-Sep-87 08:33:35 EDT
Article-I.D.: gateway.8709091233.AA01229
Posted: Wed Sep  9 08:33:35 1987
Date-Received: Fri, 11-Sep-87 01:16:05 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 31

After all of this talking about the DEC scheme, I bloody well hope that
DEC gives me a good job offer.

I didn't want to get into details over the air.  I have the breifing
slides from a presentation given at the IETF in Boston last (I think
it was) April.  They are fairly self explanatory.

Mainly, I wanted to dispel this notion that congestion control should
occur when there is congestion.  It should actually occur before there
is congestion, and that is what the DEC algorithm does.

The bit is set by gateways, and they set it whenever they have one
packet in the queue.  I believe this does not mean one packet per
source/destination pair or anything like that, simply one packet.
The bit is set in the queued packet, which means that the host
receiving the set bit is not the one that sent the packet, but the
one on the other end.  However, that one tells the sending one to
shrink its window via the normal method, and this is how the
congestion information gets back to the sending host.

Of course, the hosts have an algorithm they use to know how to
adjust the flow.  Basically, the window is increased additively
and decreased multiplicatively.  Also, the hosts filter by considering
x number of previous bits.

Again, an appeal to DEC people:  please correct me if I have
over-simplified, misrepresented, or in any other way screwed
this up.

	Paul Tsuchiya		tsuchiya@gateway.mitre.org
	The MITRE Corp.		tsuchiya@mitre-gateway.arpa