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: <7689@ucbvax.ARPA>
Date: Sat, 1-Jun-85 21:53:38 EDT
Article-I.D.: ucbvax.7689
Posted: Sat Jun  1 21:53:38 1985
Date-Received: Mon, 3-Jun-85 06:07:00 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 15

From: Murray.pa@Xerox.ARPA

I think "adjusting the timers" would help more than you give it credit
for. From my experience, the single biggest problem on large networks is
retransmitting too soon and too often.

Most code gets debugged in a local environment that doesn't have
gateways dropping packets because the next phone line (or net or..) is
overloaded. People tighten down the timers to make things "work better".

Unfortunatley, the sociology of this problem doesn't help to get it
fixed. If you increase your timeouts, you don't get any positive
rewards. It's only when almost everybody does it that anybody will get
the benefits. Even then, the finks that don't cooperate get as much
benefit as everybody else.