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!utcs!lsuc!pesnta!hplabs!ucbvax!tcp-ip
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: Re: MILNET/ARPANET performance
Message-ID: <7581@ucbvax.ARPA>
Date: Wed, 29-May-85 17:08:15 EDT
Article-I.D.: ucbvax.7581
Posted: Wed May 29 17:08:15 1985
Date-Received: Thu, 30-May-85 09:19:35 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 69

From: CLYNN@BBNA.ARPA

Mark, et.al.,

	I have also experienced many lost packets and delays
between Milnet (ISI) and Arpanet (BBN), but I was trying to FTP
800 page data files.  They always seemed to timeout.  I have
also spent a lot of time trying to make retransmissions and
flow control work a little better than they did (on TOPS20s).

	The statement that TCP reliable delivery not being
resorted to is false, theoretically.  The Arpanet and Milnet
are both reliable 1822 networks, with a nominal limit of 8
outstanding packets between Imp/port pairs.  The gateways
redirect hosts to send packets to the gateway nearest to the
sending host.

	To see the problem, consider the following diagram.

	Milnet Imp  ---Imp--- Milnet ---Imp----  Milnet Imp  -- ISIA
	    |					      |
	  BBN GW				   ISI GW
	    |					      |
BBNA --	Arpanet Imp  --Imp--- Arpanet --Imp----  Arpanet Imp

Traffic from ISIA to BBNA goes to the local imp, through the ISI GW,
across the Arpanet, to BBNA; traffic to ISI goes through the BBN GW,
cross country via the Milnet to ISIA.  The transit time through either
net is (more or less) proportional to number of hops.  Thus it takes
longer to go from the BBN GW to ISIA (via Milnet) than from BBNA to
the BBN GW (or from the ISI GW to BBNA (via Arpanet) than from ISIA to
the ISI GW), the points where the 1822 flow control is applied.
Consequently, BBNA can reliably send packets to the BBN GW faster than
the gateway can reliably get them to ISIA -- even if there is NO other
traffic in either net.  Eventually, the packets at the gateway will
build up and the gateway will have to discard the excess packets
(sending a source quench back to the host).  I.e., assume BBNA to BBN
GW is 50ms or 8 packets per 50 ms = 160 packets per second; BBN GW to
ISIA is about 300ms or 8pkt/300ms = 26 packets per second; thus 134
packets per second down the drain.  (Note that simply switching to
faster processors, e.g., a butterfly, will not help.)

	What is needed is NOT adjustment of retransmission parameters,
what IS needed is end to end flow control algorithms that work, and
some specific guidelines to those who are implementing the protocols.

	There are a few things that could be done to relieve this
particular problem.  The gateways could be programmed to redirect the
hosts to the gateway nearest the destination (so called "destination
routing" which the gateway crew is investigating).
	It isn't simple, and requires knowledge in the gateways of
	many things about topoligies and delays between pairs of
	hosts -- a long way from the "stateless" gateway originally
	described.
One can also get busy and figure out how to do flow control.
	We have added code to our TOPS20s for flow control: it
	closes windows, uses estimated baud rates to limit
	outstanding packets (instead of just filling a window),
	limits the number of packets retransmitted when one is lost,
	and it boths sends and processes source quenchs.  Even if
	this all works, it may not help much until most of the other
	hosts take similar actions.
My solution to the FTP problem was to tell it to use a source route
through the ISI GW.
	It worked because the data was all flowing in one direction
	and because the TCP will automatically invert a received
	source route option (the FTP server didn't have to be changed).

Charlie