Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!PURDUE.EDU!narten
From: narten@PURDUE.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TN3270
Message-ID: <8706031703.AA19342@gwen.cs.purdue.edu>
Date: Wed, 3-Jun-87 13:02:28 EDT
Article-I.D.: gwen.8706031703.AA19342
Posted: Wed Jun  3 13:02:28 1987
Date-Received: Sun, 7-Jun-87 01:33:06 EDT
References: <8706030415.AA08802@arthur.cs.purdue.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 26

>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.) 

Has anyone ever looked into the way EGP traffic (and the "extra hop"
problem that goes with it) effects this? For instance, on the ARPANET,
there are only 3 EGP servers sites publicly available. They are
presumably located on the east coast (10.7.0.63
bnnet2-arpanet-gw.arpa), midwest (10.2.0.37 purdue-cs-gw.arpa), and on
the west coast (10.3.0.27 gateway.isi.edu).

Does anyone have any information on numbers and locations of sites
peering with each server?  Would it help to skew the peering so that
sites on the east peered with bbnnet2, and so on, even if it means
that the percentages of the total sites each server peers with is
unequal? 

In looking at routing tables gotten via EGP from purdue-cs-gw.arpa,
only a handful (less than 40 out of 240) of the routes actually go
through those gateways. The rest go to specific (and presumably
correct) gateways. Is this because everyone else peers with Purdue
(and hence its EGP updates have the correct info) or because the
"extra hop" problem really isn't a problem since ICMP redirects get
things straightened out?

Thomas