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: ARPANET/MILNET performance statistics
Message-ID: <7957@ucbvax.ARPA>
Date: Sat, 8-Jun-85 05:54:01 EDT
Article-I.D.: ucbvax.7957
Posted: Sat Jun  8 05:54:01 1985
Date-Received: Sun, 9-Jun-85 02:46:14 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 27

From: CERF@USC-ISI.ARPA

Jim,

unless things have changed dramatically when I wasn't looking,
the IMP takes in up to 1008 bytes but breaks them into 1008 bit
packets.  The X.25 versions of the IMP take in 1024 bytes, so I
suspect the single IMP packet is probably 1024 bits long in data
field rather than 1008, for those IMPs.

The IP datagram sizes therefore tell you whether you are dealing
with single or multi-packet messages in the network.  Any
datagram larger than 126 bytes is therefore a multi-packet
message and subject to the end/end protocol for multipacket
messages.

The 8 messages outstanding problem is usually exacerbated when
there are a lot of small messages - short datagrams carrying
interactive telnet traffic are the worst case.

It's possible I wasn't very clear in what I was trying to say,
but I do believe I'm correct that the IMP still breaks up
messages larger than 126 bytes into multiple small packets of up
to 1008 bits.  I could be wrong about the 1008 bits, it could
have gone up a little, but not much beyond 1024 bits, I bet.

Vint