On Sun, Jun 15, 2003 at 09:07:09AM -0500, Donald Lee wrote:
> I read in the RFCs that MTU for non-local paths should be set to 576.
> Re-reading, I see that I was not quite right, but close.....
> 
> I'm relying on RFC 1191 and 1122
> 
> rfc 1122 says:
> 
>          section 3.3.3
> 	....
> 	 It is generally desirable to avoid local fragmentation and to
>          choose EMTU_S low enough to avoid fragmentation in any gateway
>          along the path.  In the absence of actual knowledge of the
>          minimum MTU along the path, the IP layer SHOULD use
>          EMTU_S <= 576 whenever the destination address is not on a
>          connected network, and otherwise use the connected network's
>          MTU.

I just has a look at it, and it seems you're right. We should not use the
MTU of the local segement for non-local hosts.

> 
> and 1191 (PMTU-D RFC) says:
> 
> 	introduction
> 	.....
> 	The current practice [1] is to use the lesser of 576 and the
> 	first-hop MTU as the PMTU for any destination that is not connected
> 	to the same network or subnet as the source.  In many cases, this
> 	results in the use of smaller datagrams than necessary, because many
> 	paths have a PMTU greater than 576.
> 
> Both of these are old - pre-1991.
> 
> My real authority is that NetBSD 1.6.1, the premier OS on the 'net does it
> that way. ;->

This is quite possible. All the problems we see with pppoe on adsl connections
suggests that most of the servers on the internet use large packets by
default too ...

Note that using small packets have a performance penalty: I noticed a real
drop in performances (~10%) between my ftp server at work and my client at
home, when I upgraded the server to 1.6 from 1.5.x. This is how I noticed
that the default MTU for 1.6 and 1.5.x was different.
Enabling PMTU discovery fixed the performances problem.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--