Date: 24 Mar 1996 07:19:50 -0600 From: "Richard Wackerbarth" <rkw@dataplex.net> To: "Brian Tao" <taob@io.org>, "freebsd-hackers@FreeBSD.ORG" <freebsd-hackers@FreeBSD.ORG>, "Michael Smith" <msmith@atrad.adelaide.edu.au> Subject: Re(2): Changing Ethernet frame size to 576 bytes? Message-ID: <n1384470488.95106@Richard Wackerbarth>
next in thread | raw e-mail | index | archive | help
>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. What is bogus about his arithmetic? If the losses are infrequent and not highly correlated, each loss causes a retransmission of the entire large packet. This causes the number of bytes retransmitted, and therefore the effective loss rate, to be multiplied by the fragmentation ratio. > 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. Although the original observation is correct, I believe that he is attacking the wrong member of the link. It would appear that we are doing things most appropriately and have nothing that WE should change. Do we cache the MSS or do we always start with a large value? Cacheing would be a "win" for the case of many short connections. (like www that does not use ttcp)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?n1384470488.95106>