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: <7596@ucbvax.ARPA>
Date: Thu, 30-May-85 12:08:40 EDT
Article-I.D.: ucbvax.7596
Posted: Thu May 30 12:08:40 1985
Date-Received: Fri, 31-May-85 04:04:18 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 36

From: CERF@USC-ISI.ARPA


Folks,

Gateway performance IS important.  Especially for DoD where the
whole point of internet was to capitalize on connectivity where
ever it could be found; in a crisis, the traffic goes where it
can.

I think the gateway performance has been decreasingly
satisfactory as the level of traffic has built up.  Clearly, the
character-echoplex requirement exacerbates matters a good deal,
and the 8 messages outstanding rule on the ARPANET and MILNET
make the problem more severe since traffic gets throttled below
the TCP/IP level as a result (the new END/END protocol in the
IMPs should help some).

Are there any hard data about gateway throughput - Dave Mills
always seems to have his hands on measurement information - how
about it, Dave?

Can BBN say anything about higher capacity gateways under
development?

Before we tar the LSI-11/03 gateways, let's try to find out where
the bottleneck is - for all I know it is other than the gateway
itself.  I remember that in the Ft.  Bragg Packet Radio
experiments we found that 8 messages outstanding were the real
bottleneck and quickly went to line at a time application support
to reduce the packet rate.  This was particularly acute at Bragg
because nearly every appliation ran on the SAME host and the 8
message limit applied between that host (ISID) and the gateway
qua host on ARPANET.

Vint