[508] in linux-net channel archive
Re: CONFIG_INET_SNARL: What for?
daemon@ATHENA.MIT.EDU (Craig Metz)
Thu Jun 15 08:22:09 1995
To: Michael Shields <shields@tembel.org>
CC: linux-net@vger.rutgers.edu
In-reply-to: Your message of "Thu, 15 Jun 1995 00:46:41 GMT."
<m0sM350-000DTMC@yage.tembel.org>
Date: Thu, 15 Jun 1995 06:55:50 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
In message <m0sM350-000DTMC@yage.tembel.org>, Michael Shields writes:
>> In
>> the vast majority of environments, SNARL actually still does benefit you
>> because it will increase the number of (sub)networks on which you will use
>> a large MSS from one (ONLY your local subnet) to (n::n > 0) where n is based
>> on your classed allocation size and subnet mask. In no case that I can see
>> will it actually hurt you.
>
>Let's say I get a /28 from one of my provider's class C's.
This is uncommon.
>SNARL will
>consider the "all subnets" mask to be 255.255.255.0, which is broader
>than the correct value of 255.255.255.240.
This is so. So, as Alan said quite correctly, you hit "n" when the
kernel configuration asks you about this. This is why SNARL is an *option*.
>This means that packets to
>other sites in the same class C will be sent with a large MTU over that
>small-MTU link, simply because we happen to have similar addresses.
No, it doesn't. It means that packets within the Class C will be sent
with a large MSS over that small-MTU link. It still could give you better
performance because intermediate loss of fragments is less likely within your
provider than it is with the net at large, but it will not actually do so if
you use VJ IP+TCP header compression on the link to your provider because
fragmentation shuts off compression for the packet.
Again, the solution to all of these problems is Path MTU Discovery.
Until then, SNARL is frequently a win and you can just hit "n" if it is a loss
and turn it off.
-Craig
