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!burl!ulysses!ucbvax!tcp-ip
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: Re:  MILNET/ARPANET performance
Message-ID: <7564@ucbvax.ARPA>
Date: Wed, 29-May-85 04:33:31 EDT
Article-I.D.: ucbvax.7564
Posted: Wed May 29 04:33:31 1985
Date-Received: Thu, 30-May-85 07:25:19 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 65

From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>

	I feel that I really ought to say a few words in defense of the
gateway maintainers at BBN, who I think are possibly being unjustly
maligned. (I'll try to keep this short, but it is a complex topic.
Please excuse cryptic references; I'm not trying to write a paper!)

	I'm not so sure that the real problem is in their gateways. I
don't have any exact performance figures for their gateways, but my
long experience with LSI11 gateways and MOS indicates to me that
gateways built with that technology can run at over 200 packets/second,
way fast enough to sink an IMP. I don't know if their gateways go quite
that fast, but they can probably handle packets fast enough to swamp
the ARPANet.
	I'm also not sure how much the limited number of buffers in an
LSI11 matters. When the Stanford LSI11 gateway I maintain was upgraded
to use memory mapping and have lots of buffers, the performance was
not greatly improved. (Adding something called RFNM counting did improve
it, but the BBN gateways have had that for a long time.)

	I would point at two possible causes for the problems. The
first is that the ARPANet itself is simply not designed to handle the
style of traffic load that gateways present, and I wouldn't be
surprised if it isn't overloaded anyway. (I've heard some comments from
BBN people that indicate it is.) I don't have any load measurements
from before the conversion to TCP (~1980) but I wouldn't be surprised
if it was up from then. Perhaps someone in BBN could look up some
figures? For aficionados of fine details, there is also a problem
called 'resource blocking' that active hosts run into, which there is
no way for host software to guard against. It results in all outbound
traffic freezing for 15 seconds.
	Also, there are a limited number of gateways between the two
nets; the largest share of the load is handled by 3, the ones at DCEC,
ISI and BBN. 'Well', you say, 'no problem, the IMP's work fine with the
same number of connections. Why not the gateways?' The answer is that
the IMPs cooperate among themselves much more closely, and in addition
have control over the rate at which traffic is let INTO THE NETWORK!
IMP's can always refuse to take packets from the hosts if the resources
to deal with them are not available. Gateways have no such control; the
get given the packets and have to deal with them as best they can.

	This leads on to the final point, which Mark alluded to in
his comment about 'throwing out a lot of packets'. This is precisely
what an overloaded gateway does, and in fact it is about the only
defense mechanism it has. Needless to say, this results in terrible
performance; in addition, network resources are wasted delivering the
packet to the point at which it is discarded.
	Sad to say, Mark, adjusting the timers will probably not help
much. The problem is that any retransmission algorithm is guessing
based on incomplete information; things will always be non-optimal (and
there's probably a Shannon theorm that proves it). You'll either have
lots of waits, or waste lots of resources retransmitting when you don't
need to, (and making things worse by using those resources).

	What the network really needs to deal with these problems are
better congestion and traffic control (the ability to regulate the
traffic flow in the system better), and a lot more information passed
back to the hosts to allow them to make optimal use of the network.
	These are all just symptoms of a deeper truth, which is that
building really big packet switched networks is still emerging
technology. Understanding of problems and proposals of new mechanisms
to handle them are appearing, but there is still a way to go.

	Noel
-------