Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!ames!ucbcad!ucbvax!Sierra.Stanford.EDU!GROSSMAN
From: GROSSMAN@Sierra.Stanford.EDU (Stu Grossman)
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  Analyzing Acknowledgement Strategies, continued
Message-ID: <12272778635.31.GROSSMAN@Sierra.Stanford.EDU>
Date: Wed, 21-Jan-87 17:26:33 EST
Article-I.D.: Sierra.12272778635.31.GROSSMAN
Posted: Wed Jan 21 17:26:33 1987
Date-Received: Thu, 22-Jan-87 02:07:47 EST
References: <8701191933.AA00226@apolling.imagen.uucp>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 29
Approved: tcp-ip@sri-nic.arpa

When I was at DEC, Raj Jain gave a paper on this subject, but it seemed to be
somewhat more refined than the work you mentioned.  Essentially, he was trying
to deal with congestion Control, not congestion Prevention.

The method he proposed went something like this:
1) Under conditions of no congestion, send as many packets as you want.

2) When congestion is first detected, reduce the number of outstanding
   (unacknowleged) packets to 1.

3) Increase the number of outstanding packets until either:
	a) the number of outstanding packets is equal to three times the
	   number of hops between you and your destination, or
	b) congestion is detected again, go back to step 2.

The number of outstanding packets is increased by one each time you have
successfully transmitted all of your previous outstanding packets without
detecting congestion.

I don't recall the particulars of how the congestion is detected.

This method was used in DECnet and did indeed make congested situations
much more palatable.  One of the primary cases where this algorithm helped
a lot was in the case where you had a gateway (pardon me, a DECnet router)
with interfaces to networks of differing speeds on each side (such as an
Ethernet and a 19.2kb line).

			Stu Grossman
-------