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: <7963@ucbvax.ARPA> Date: Sat, 8-Jun-85 18:50:09 EDT Article-I.D.: ucbvax.7963 Posted: Sat Jun 8 18:50:09 1985 Date-Received: Mon, 10-Jun-85 07:22:29 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 25 From: Mike Brescia Vint, Ron, Dave, Marianne, &al. The statistics collected from the BBN gateways include only total packet counts and total byte counts. The average reported is (you guessed it) byte-count divided by packet count. There's no facility for histograms, maxima, standard deviation, or other interesting statistics. The gateways currently fragment in the manner you recall, Vint, with the first fragment(s) being as large as possible, and the last one containing the leftovers. The idea of splitting a datagram as close to the half-way (or 1/N if N fragments are needed) was not deemed useful for the arpanet, because the end-to-end overhead is the same for a 130 byte or 576 byte packet as for a 1000 byte packet. The best policy for the arpanet was to get the packets large as possible. My intuition about MILISI carrying larger packets than others is that ISI has large hosts (TOPS20) on both sides of the mil-arpa divide, and they may do lots of file transfers (ftp big packets) or screen outputs (telnet big packets). One of the ISI wizards may be able to shoot holes in that speculation... Good hunting, Mike