[490] in linux-net channel archive
Re: CONFIG_INET_SNARL: What for?
daemon@ATHENA.MIT.EDU (Craig Metz)
Wed Jun 14 10:11:57 1995
To: "C. Harald Koch" <harald@enfm.utcc.utoronto.ca>
CC: linux-net@vger.rutgers.edu
In-reply-to: Your message of "Tue, 13 Jun 1995 16:25:59 -0400."
<95Jun13.162605edt.606955@enfm.utcc.utoronto.ca>
Date: Wed, 14 Jun 1995 07:40:30 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
In message <95Jun13.162605edt.606955@enfm.utcc.utoronto.ca>, "C. Harald Koch" w
rites:
>The acronym stands for "SubNets ARe Local", if I understand correctly.
Yes.
>Internet standards specify that when you're talking to a remote network (via
>a gateway), you must use an MTU of 576 bytes.
NO! If you are talking to a remote site, you cannot assume without
other a priori knowledge that the remote host's reassembly buffer can properly
reassemble packets of a total length of more than 576 bytes. MTU has nothing
to do with this. Fragmentation/reassembly takes care of MTU for you.
>However, when you've got a bunch of local Ethernets (for example) all
>connected by a router, using 576 bytes is inefficient, since you could be
>using the 1500 byte Ethernet MTU instead.
Correct.
>SNARL tells the kernel that it should assume that subnets of a locally
>attached, class-full network should be considered "local" networks, and
>should use the default MTU of the local interface.
Not quite.
In Linux, SNARL attaches a default MSS to the socket data structure
of either (576 - HEADER_SIZE) [448] if the network is "remote" or (MAX_WINDOW)
[16384] if the network is "local". All of this happens ONLY when the user
process has not set an MSS and when there is not an MSS set for the route
being used.
For reference, in 4BSD, a similar algorithm sets the MSS to (route MTU
- sizeof(struct tcpiphdr)) if there is a route MTU or (interface MTU
- sizeof(struct tcpiphdr)) if not. If the destination is later deemed "non-
local", the MSS is set to the lesser of its current value or 512 (tcp_mssdflt).
>[ SGI's kernel also has an "allnetsarelocal" config paramater, which is
>useful for local internets. It does the same thing, but uses the local
>interface MTU for *all* outbound traffic. ]
Where you don't have Path MTU Discovery, this is reasonable - just
let your fragmentation engine handle it. Most links on the net today have a
MTU of 1500 bytes and will carry frames from an Ethernet end-to-end without
fragmentation. Smaller links will fragment, and you will lose some performance
(a LOT if you have high packet loss rates) on those links. On the other hand,
the links with smaller MTUs are generally not fast anyway (i.e., SLIP). The
solution to this problem is Path MTU Discovery, which will figure out what
the end-to-end MTU is and set the MSS appropriately to get maximum performance
by making the packets as large as possible without fragmenting.
>Now, SNARL is a good hack, but the real answer is to use MTU Discovery.
Correct.
-Craig
