Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!G.BBN.COM!CLYNN
From: CLYNN@G.BBN.COM
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Maximum sized IP packets
Message-ID: <[G.BBN.COM]21-Apr-88.10:02:23.CLYNN>
Date: 21 Apr 88 14:02:00 GMT
References: <8804210028.AA07717@hamlet.ultra.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 19

Bob,	I have sent and reassembled datagrams up to about 28K bytes
on the TOPS-20;  I never tried the 64K experiment.  The size of the
datagram makes the probability of at least one lost fragment
approach 1.0.  In such cases, the reuse of IP ID by the transport
layer (e.g., TCP, UDP) is very important, and the way the network
driver sends the group should be considered carefully (e.g., leaving
a little time between successive fragments (both to prevent back-to-
back packets and to give others a chance to use the resources));
the relationship between IP TTL and transport retransmission timeouts
and exactly how IP reassembly timeout is handled makes a big difference.

What is practical depends on the environment, and the implementation(s).
There is "no problem" across the ARPANET or MILNET as they have high end-
to-end reliability;  there is a problem across the ARPANET and the MILNET
(the gateway queues between them).  There should not be significant problems
across a (segmented) lan.  If monstergrans are IMPORTANT, we can write the
software to get them through, but there is a high penalty in wasted
bandwidth and cpu cycles if retransmissions are required.

Charlie