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: <7578@ucbvax.ARPA>
Date: Wed, 29-May-85 15:44:39 EDT
Article-I.D.: ucbvax.7578
Posted: Wed May 29 15:44:39 1985
Date-Received: Thu, 30-May-85 06:06:36 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 40

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

	Ron, I'm not sure I completely believe that one either,
although there is some truth to it.

	(To explain to the rest of the list what (I think) he is
alluding to, the routing protocol the BBN gateways use among
themselves, GGP, is somewhat deficient (not really its fault since it
is an ancient protocol) and cannot advise gateways of the existence of
routes that do not pass through the gateway sending the information.
To make that a little plainer, consider the concrete example of the
MIT ARPANet gateway communicating routing info via EGP with a gateway
on the ARPANet at BBN; the BBN gateway has no way, inside GGP, of
letting a gateway on the ARPAnet at ISI know that it can get directly
to MIT by going straight to the MIT ARPANet gateway. All traffic from
ISI to MIT must go via the BBN gateway.)

	It is true that this will tend to clog up the network as
a whole by sending such packets through the ARPANet twice when once
would have done. (Solving this requires replacing GGP. As I understand
it, there was a definite decision to do this in the context of the
Butterfly upgrade. I gather the schedule for that delay has slipped;
I'm not sure where the responsibility lies. You can argue about whether
that was a wise decision, as opposed to spnding resources in upgrading
the LSI11 gateways as a bandaid.)

	However, traffic from the MILNET to the ARPANet should not be
affected directly by this problem. It is true that the network
provides no way for a host (or gateway) to pick the optimum
MILNET/ARPANet gateway from the set available; this is because the
ARPANet looks like an atomic network at the IP routing level, when in
fact as we all know it is a set of links. For this reason it is
important for hosts to set the default ARPANet/MILNet gateway by hand,
using oiutside knowledge of the ARPANet topology to pick the optimal
one.
	Fixing THAT problem in some non-kludge way is yet another large
unattacked issue.

	Noel
-------