Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!ALEXANDER.BBN.COM!fserr
From: fserr@ALEXANDER.BBN.COM.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TN3270
Message-ID: <8706022259.AA08519@ucbvax.Berkeley.EDU>
Date: Tue, 2-Jun-87 22:09:33 EDT
Article-I.D.: ucbvax.8706022259.AA08519
Posted: Tue Jun  2 22:09:33 1987
Date-Received: Fri, 5-Jun-87 01:33:12 EDT
Sender: dlw@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 30

The ARPANET had severe performance problems last October, and again 
during late January and February.  In both cases we think the major
culprit was oversubscribed network trunks.  The network routing
algorithm started thrashing about, looking for less congested routes.
This sometimes led to less efficient use of the existing bandwidth,
compounding the performance problems. 

Last fall the problems were triggered by trunk rehomings that were 
done in the wrong order.  The most important "fix" was simply getting
all the rehomings done, restoring the bandwidth that had been there
before.  

The congestion in February was alleviated by adjustments to the 
parameters used in the network routing calculations.  We lessened the
ability of the network to route around congestion, but made it more
stable in the face of limited bandwidth on important routes.  Upgrading
several key nodes to a more powerful hardware version may have had a
small role in keeping performance at acceptable levels.  

Though things seem OK now, the network is still sensitive to increased
traffic on key paths.  (Transcontinental bandwidth seems to be the
critical resource here.) Sometime very soon (perhaps this week), a new
link will be added to the ARPANET between New England and northern
California.  This new cross-country trunk should improve performance
still further, and start to provide some room for expansion beyond
current traffic levels. 

Fred Serr
Network Analysis Department
BBN Communications