Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-unix!sri-spam!ames!ucbcad!ucbvax!UCBVAX.BERKELEY.EDU!karels%okeeffe
From: karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: IP Datagram sizes
Message-ID: <8705262316.AA08021@okeeffe.Berkeley.EDU>
Date: Tue, 26-May-87 19:16:32 EDT
Article-I.D.: okeeffe.8705262316.AA08021
Posted: Tue May 26 19:16:32 1987
Date-Received: Thu, 28-May-87 01:18:58 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 41

There are a few other points in this discussion that haven't made.

One it that looking at IP fragmentation in received packets
doesn't work for one-way connections (FTP) or connections with
asymmetrical data flow (Telnet, most everything else).

As Doug pointed out, using large packets and depending on IP fragmentation
looses badly when the network becomes lossy.  I've always resisted
paying for 2 different fragmentation/reassembly mechanisms at once,
and only the TCP level allows acknowledgement (and progress) when only
part of the data gets through.  Also, under various circumstances,
IP datagrams may be fragmented more than once, resulting in lots
of packets of varying sizes, lots of them tiny.  When this happens,
hardware or software limitations are likely to cause some of these
small packets just after larger ones to be lost.  (One such bug
in the ACC LH/DH and the 4.2BSD driver caused 1024-byte packets
to be lost with high probability because of fragmentation.)

There were a few comments about use of larger sizes on the local
network(s).  4.3BSD's algorithm is to use a large size under the MTU
of the outgoing network interface if the destination is on the same
logical network (another subnet of the same network is considered local).
This assumes that the MTU on any segment of the network is not unreasonably
bad for other parts of the network.

If packet size for a path is determined and propagated by the routing
protocols, that wouldn't help hosts that don't listen to the routing
protocols.

I would very much like to see options for determining the min MTU,
min throughput and the hopcount of a path.  In order to return the
information to the sender, this would have to be done as an ICMP
message that is reflected and returned by the destination, or hosts/
gateways would have to use the convention of preserving such IP options
when echoing ICMP messages.  If this was an ICMP message, it could
be defined so that each gateway replaced the IP destination address
with the IP address of the next-hop gateway so that gateways need not
examine each datagram forwarded.  The original IP address would be
stored in the ICMP part of the packet or in an IP option.

		Mike