[475] in linux-net channel archive
Re: CONFIG_INET_SNARL: What for?
daemon@ATHENA.MIT.EDU (Craig Metz)
Tue Jun 13 15:41:06 1995
To: Matthias Urlichs <urlichs@smurf.noris.de>
CC: linux-net@vger.rutgers.edu
In-reply-to: Your message of "13 Jun 1995 11:35:09 +0200."
<3rjm4e$tlk@smurf.noris.de>
Date: Tue, 13 Jun 1995 13:53:28 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
In message <3rjm4e$tlk@smurf.noris.de>, Matthias Urlichs writes:
>CONFIG_INET_SNARL selects whether to use the netmask of a device (set by
>ifconfig) or the IP-class-default netmask (i.e. 255.255.255.0 for a class C
>address) for figuring out which MTU to use for TCP.
>
>I wonder what the reason for this is. I can't think of any correctly-
>configured machine where the latter behavior would make any more sense than
>the former, yet the latter is the default (and more expensive to compute).
>On the other hand, for networks with non-default netmasks, I can think of a
>few cases where the former behavior would make much more sense.
>
>Thus, I vote to get rid of CONFIG_INET_SNARL. Let the following patch apply:
If I am not mistaken, this behavior comes somewhat from the way that
4BSD handles this problem. The key here is that it assumes that you have the
same MTU as the local network on ANY network within your classed network
allocation. I.E., if I am at a site with a Class B address space that is
subnetted into eight-bit chunks, and my box is plugged into subnet 42, it
assumes that subnet 43 is going to have the same path MTU as subnet 42, which
would usually be the case unless there is a WAN link in the middle (e.g.,
there only being Ethernets in the path). Without SNARL, the assumption made
is that ANY network not the one your box is physically attached to is remote
and needs to have the remote MTU.
The CORRECT solution to this problem, IMO, is to implement Path MTU
Discovery. With IPv4, however, this is easier said than done (but still not
*TOO* hard). Then this whole nonsense of trying to guess the correct MTU for
the network goes away.
-Craig
