Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/15/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!whuxl!houxm!mhuxt!mhuxr!ulysses!ucbvax!tcp-ip
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: Re: MILNET/ARPANET performance
Message-ID: <7692@ucbvax.ARPA>
Date: Sun, 2-Jun-85 00:15:33 EDT
Article-I.D.: ucbvax.7692
Posted: Sun Jun  2 00:15:33 1985
Date-Received: Mon, 3-Jun-85 06:07:17 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 25

From: Lixia Zhang <Lixia@MIT-XX.ARPA>

I would support Noel's view point that "adjusting the timer will not help
much" in an overloaded net.  Consider the following arguments:

- Timers, in general, are not shorter that a normal round-trip delay,
  even in the case as you mentioned, "most code gets debugged in a local
  environment".

- Therefore in most cases, if there is a series of timeouts, it is
  started with jammed or lost packets.  This means that somewhere in the
  net gets overloaded by CURRENTLY offered data traffic.

- The window size = outstanding data = traffic load offered to the net.

- Therefore without reducing the window size
                                 -> no reduction on network load
                                          -> no help to the overloaded net.

- It is true that retransmitting too soon and too often will further damage
  the situation, but simply adjusting the timer to hold up retransmission
  longer will NOT resolve the congestion.

Lixia
-------