From owner-freebsd-hackers Sun Mar 24 00:29:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA12373 for hackers-outgoing; Sun, 24 Mar 1996 00:29:21 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA12353 for ; Sun, 24 Mar 1996 00:29:04 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id TAA24105; Sun, 24 Mar 1996 19:15:50 +1030 From: Michael Smith Message-Id: <199603240845.TAA24105@genesis.atrad.adelaide.edu.au> Subject: Re: Changing Ethernet frame size to 576 bytes? To: taob@io.org (Brian Tao) Date: Sun, 24 Mar 1996 19:15:50 +1030 (CST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Brian Tao" at Mar 23, 96 10:27:38 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brian Tao stands accused of saying: > > Anyone know what this guy is saying? I figured fragmentation and > reassembly would happen between the FTP server's Ethernet interface > and that of the router to the Internet. Is there any validity to this > guy's suggestion? Er, "yes" some of what he says is valid. No, he's not drawing any sensible or meaningful conclusions from it. > Brian Tao (BT300, taob@io.org) ... > Partly this is due to overloaded links, but I also notice that your > ftp server at ftp.io.org seems to be configured to send Ethernet sized > (ie 1536 byte) packets, instead of the normal Internet 576 byte packets. You can discount the "normal Internet packet size" concept; there ain't no such animal. As has been already observed, 576 is the minimum permitted MSS. > This means that every IP packet you send has to be fragmented into three > IP fragments as it travels over the Internet, and if any single one of This only happens if your data has to move over a link imposing a smaller MSS. Not many do - mostly PPP and SLIP links. > those fragments is lost, then the other two are useless, even if they do > arrive. In other words, if your link is congested and is losing 20% of > the packets, then those losses make the other two fragments useless too, > giving you an 'effective' loss rate of 60%. This is bogus arithmetic; lossage is a normally a point event and results in the loss of one unit datagram around the point, regardless of its size. This is why small-packet proocols (like kermit) fare better on noisy uncorrected lines than large-packet protocols like Ymodem. > Of course, I may be wrong. It's just a guess, based on what I noticed from > this end, that the ftp data seemed to be arriving in 1536 byte chunks. This is most likely because the systems responsible for the 576-byte MSS cutdown (wherever they may be - I suspect his end of things) are not cooperating with the path MTU discovery performed by FreeBSD, and thus your FTP server (mistakenly) believes that it can send a 1536-byte segment without fragmentation. If he's really keen, you could suggest that he should establish at what point the fragmentation occurs, and determine the offending hardware/software so that he can the proceed to bug the losing vendor(s) to fix their code. > Stuart Cheshire ... > * Macintosh Programmer Not to be a bigot, but the Apple TCP code seems to leave a lot to be desired. It would be educational for someone to point the MTU discovery code at one and see if it behaves... -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[