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!cbosgd!ucbvax!tcp-ip
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: Re: ARPANET/MILNET performance statistics
Message-ID: <7713@ucbvax.ARPA>
Date: Mon, 3-Jun-85 06:03:27 EDT
Article-I.D.: ucbvax.7713
Posted: Mon Jun  3 06:03:27 1985
Date-Received: Wed, 5-Jun-85 01:20:50 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 31

From: CERF@USC-ISI.ARPA

Dave,

Thanks very much for a most helpful summary. One thing which I note
about the MILISI gateway, in addition to its having far more traffic
that most others is that its packet size (per datagram) is larger
than a single packet message, assuming the avg bytes you show do NOT
include all the TCP/IP header bytes which must fit inside the text
of a single packet message. If memory serves, these messages have room
for at most 1008 bits or 126 bytes, some of which have to be given over
to IP or TCP header.

If I'm correct in this analysis, the MILISI gateway is injecting a good
deal of multi-packet traffic which puts a potential strain on the 
current imp end/end protocol. I note that MILISI has a higher rate of
datagram dropping - one might guess this is a result of increased
buffer demands and possibly increased incidence of timeouts for multipacket
transmission permission?

Dave is right about the need to fix those wayward implementations which
try to treat all nets as if they are identical in performance. To borrow
from Jack Haverty: You can fool some of gateways all of the time and
all of the gateways, some of the time, but you can't...

The whole SYSTEM has to be thought of as a system and all parts need
to meet some standards of performance and adaptation.  If this is
not achievable (and it's a big challenge) then nets and gateways need
to find ways to cut off identifiable abusers.

Vint