[76808] in North American Network Operators' Group
Re: Smallest Transit MTU
daemon@ATHENA.MIT.EDU (Joe Abley)
Wed Dec 29 19:44:56 2004
In-Reply-To: <OFFF8B4537.89708A6B-ON88256F79.0080B823-88256F79.0082BD88@us.ibm.com>
Cc: nanog@merit.edu
From: Joe Abley <jabley@isc.org>
Date: Wed, 29 Dec 2004 19:43:53 -0500
To: Tony Rall <trall@almaden.ibm.com>
Errors-To: owner-nanog-outgoing@merit.edu
On 29 Dec 2004, at 18:48, Tony Rall wrote:
> On Wednesday, 2004-12-29 at 17:04 EST, Joe Abley <jabley@isc.org>
> wrote:
>
>> Are there any common examples of the DF bit being set on non-TCP
>> packets?
>
> Common? It depends on what you're doing. To some people, the only
> common
> application is 80/tcp.
Sure. However, path MTU discovery is a tweakable knob in the TCP stack
on the server operating systems of my acquaintance. Turning it on (and
it's on by default most of the time, as we know, hence this thread) on
those platforms has no impact on any other protocols.
> Remember that the DF bit is in the IP header - it can be on in any
> protocol. I know that AIX and my old RH Linux (at least) defaults to
> PMTUD enabled for tcp and udp. You can even see it in dns lookups.
I am not unappreciative of the layering violations involved. I am also
happy to report that I have no recent experience of AIX or Red Hat
Linux, though, and so my observations above may well be atypical. It'd
be interesting to sample some representative traffic on some
substantial peering link somewhere and see how many non-TCP-bearing,
non-traceroute-looking datagrams have it set.
My reading of RFC 1191 suggests that the MSS tweak solution for TCP
ought to be automatic on well-implemented clients attached to a
sub-1500-byte MTU link. I guess the problem is either the number of
residential gateways that people are using which shift the
MTU-depressed link one hop away from the client, or a prevalence of
poorly implemented 1191 in clients (or both).
It's tempting to look at the amount of residential DSL that continues
to be sold and supported with sub-1500-byte MTUs and conclude that TCP
must be all we have to worry about; however, for most of those users
the only protocol on the Internet is probably 80/tcp, as you mentioned,
and so their perceived happiness probably means nothing.
>>> The better solution is to ensure that PMTUD works correctly for your
>>> network, and get on the case of any correspondent or provider for
>>> which it doesn't.
>>
>> Making sure that pMTUd works in your own network doesn't solve the
>> problem. You need to make sure it works properly in every other
>> network
>> with which you ever might want to exchange a 1500-byte packet.
>
> I thought that's what I just said.
So you did. Sorry about that.
The "phone everybody in the world with a broken firewall" solution is
better if you are viewing it from a context in which it is possible to
execute in non-infinite time. For more general applications (e.g. those
with customers) an MSS tweak on the client that avoids the broken bits
of the remote-end firewalls from being exercised most of the time is
probably a more practical route.
Joe
