[29176] in North American Network Operators' Group
Re: PMTU-D: remember, your load balancer is broken
daemon@ATHENA.MIT.EDU (Valdis.Kletnieks@vt.edu)
Wed Jun 14 11:08:50 2000
Message-Id: <200006141506.e5EF6cL21756@black-ice.cc.vt.edu>
To: Marc Slemko <marcs@znep.com>
Cc: nanog@merit.edu
In-Reply-To: Your message of "Tue, 13 Jun 2000 22:36:08 MDT."
<Pine.BSF.4.20.0006132135340.572-100000@alive.znep.com>
From: Valdis.Kletnieks@vt.edu
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_281271532P";
micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Wed, 14 Jun 2000 11:06:37 -0400
Errors-To: owner-nanog-outgoing@merit.edu
--==_Exmh_281271532P
Content-Type: text/plain; charset=us-ascii
On Tue, 13 Jun 2000 22:36:08 MDT, Marc Slemko said:
> I shouldn't get started here. I have trouble buying into HP's
> way of doing things (I was only aware that HPUX did this; but it seems
> that AIX does too...). If you run a high traffic DNS server
AIX started supporting PMTU-D for both TCP and UDP in 4.2.1. The gotcha
was it being on by default in 4.3.3.
> on an AIX box without disabling this "feature" then you must just
> be spewing ICMP echo requests. It could add up to more bytes
> than your DNS responses...
Well, as I said, it was done in error, and yes, the bytes for the ICMP
*were* running almost as high as the actual NTP traffic...
The surprising part is that it was broken for close to 3 months before
somebody noticed (yesterday, just a few hours before this discussion started,
in fact).
As noted, PMTU-D for TCP is a lot lighter weight, and has an actual chance
of winning sometimes. Does anybody know of a UDP-based application that is
able to *do* anything with PMTU-D? A co-worker had heard of research at
PSC that dealt with TCP-friendly multicast, but that was all we could think of...
> And, obviously, ICMP pings don't work too well much of the time
> anyway. And I'm concerned about the possibility of some nasty DoS
> potential by exploiting this. I haven't looked into this in depth, and
> it depends on how it handles cache replacement, etc.
> Except that, technically, you are not permitted to just blindly send
> segments of such size. Well, you can but systems in the middle don't
> have to handle them. No?
Hmm.. either I did a bad job of explaining or I haven't had enough caffiene
to parse what you said. Given that you also suggest going to a 1460 MSS,
I suspect that we're actually violently in agreement here.
Now if I can remember why I chose 1396 for a default MSS.... ;)
> It is also a concern that, in my experience, many of the links with
> MTUs <1500 are also the links with greater packet loss, etc. so
> you really don't want fragmentation on them.
The worst part here is that I suspect that most of these links (just on
sheer numbers of shipped product) are the aformentioned Win98 576-MTU.
However, in this case, the fragmentation happens in a terminal server on
the last hop, and hopefully the case of a terminal server running out of
queueing buffers and having to drop one of the 2 remaining fragments of
a 1500->576 split after sending the first one is pretty rare....
I seem to remember that the *original* motivation for slow-start and
all that was Van Jacobson's observation that the most common cause of
a TCP retransmit was that an *entire* packet had been silently dropped
due to queueing congestion, and could thus be treated identical to
an ICMP Source Quench.
Has this changed? Has "fragmentation" become a Great Evil, rather than
an annoyance that some links have to deal with?
> I think it is simply that we the net is in a state of somewhat
> amazing homogoney right now. I don't think this will continue,
> but who knows. I do think that PMTU-D is an important feature, and
> people should be encouraged to leave it enabled wherever possible,
> so that one day if networks do change to make it more useful in the
> general case, it will be there...
At least for TCP. I'm still unconvinced for UDP ;)
--
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
--==_Exmh_281271532P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2
Comment: Exmh version 2.1.2 06/07/2000
iQA/AwUBOUeffXAt5Vm009ewEQL3dwCcCWJbcyCgN2rsvRU1a2pIbN9WeJsAoN1o
KEPesVt5umNAs2IQQqt3zJXX
=Vb14
-----END PGP SIGNATURE-----
--==_Exmh_281271532P--
