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: Fragging ARPAnet gateways Message-ID: <7782@ucbvax.ARPA> Date: Tue, 4-Jun-85 15:21:45 EDT Article-I.D.: ucbvax.7782 Posted: Tue Jun 4 15:21:45 1985 Date-Received: Thu, 6-Jun-85 03:57:51 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 28 From: Jeff Mogul IP fragmentation is admittedly a bad thing to do on a regular basis. BRL avoids this by keeping most of our LAN's at 1008 (for historical reasons mostly, the gateways originally didn't know how to fragment). One of the less successful performance "improvements" in 4.2BSD was that the TCP tried to use 1024 byte segments, since this allowed 4.2 to use page-remapping techniques instead of copying. However, this is really a complete loss in our environment, where we had Vaxen connected to a 3Mb ether which is gatewayed to the ARPAnet (the current hardware situation is a little different). FTPing from another 4.2 machine across the ARPAnet would seldom work, because those 1024-byte segments turned into an almost-1024- byte fragment followed by a tinygram. The local gateway dumps the tinygram onto the ethernet almost immediately following the first fragment, and the Vax interface (no buffering) drops back-to-back packets, i.e., the tinygram. This happens over and over, so even though 90% of the bytes are getting through, the segment is never acked and the connection fizzles. We solved this by hacking the TCP code to force 576-byte segments unless it is sure that no gateway was in the path, in which case it uses the LAN MTU. This works fine, and we can keep our LAN MTUs high (1500 bytes) to reduce the packet counts in the dominant case.