Date: Sun, 24 Mar 1996 19:15:50 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: taob@io.org (Brian Tao) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Changing Ethernet frame size to 576 bytes? Message-ID: <199603240845.TAA24105@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.BSF.3.91.960323222600.8944G-100000@cabal.io.org> from "Brian Tao" at Mar 23, 96 10:27:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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 <cheshire@cs.stanford.edu> ... > * 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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603240845.TAA24105>