Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!ucbvax!MONK.PROTEON.COM!jas
From: jas@MONK.PROTEON.COM (John A. Shriver)
Newsgroups: comp.protocols.tcp-ip
Subject: IP fragmentation, and how to avoid it
Message-ID: <8705141433.AA01446@monk.proteon.com>
Date: Thu, 14-May-87 10:33:24 EDT
Article-I.D.: monk.8705141433.AA01446
Posted: Thu May 14 10:33:24 1987
Date-Received: Sat, 16-May-87 10:39:21 EDT
References: <12640@teknowledge-vaxc.ARPA>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 22

The SunOS TCP will choose to put 1024 bytes of data in each packet
unless the socket receive high water mark is lower (so_rcv.sb_hiwat).
This is straight out of the 4.2BSD VAX code, without any change.  (At
least as of SunOS 3.2.)  Indeed, this will result in the IP packets
being fragmented on the ARPANET, which is a lose.  IP fragment
reassembly is far less robust than TCP reassembly.

This code is fixed in 4.3BSD, where it sends large packets only to
hosts on the same net (LAN), and otherwise limits istelf to 576 byte
packets.  The same code also allows the data to open up beyond 1024
bytes if you have a LAN with large MTU.  This can dramatically
increase local TCP performance.

Bother your Sun technical support contact to encourage them to fix
this.  It involves adding one subroutine (tcp_mss()), and tweaking
tcp_output().

As for tweaking the MTU, I don't think that it will hurt NFS, as it is
already sending 8192 byte UDP packets that are being fragmented by the
IP layer.  I have no idea what effect it will have on ND, since ND is
proprietary.  However, better to fix the problem (TCP) than to have to
crock around it (MTU).