[150290] in North American Network Operators' Group
RE: Common operational misconceptions
daemon@ATHENA.MIT.EDU (George Bonser)
Mon Feb 20 21:12:00 2012
From: George Bonser <gbonser@seven.com>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Date: Tue, 21 Feb 2012 02:11:03 +0000
In-Reply-To: <4F42E275.50608@necom830.hpcl.titech.ac.jp>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> -----Original Message-----
> From: Masataka Ohta
> First, it sets eff_pmtu to 1400B. OK?=20
Where did you get 1400 from? Are you talking specifically with the linux i=
mplementation? =20
"As eff_pmtu of 1400B is close enough to search_high, you are done."
I suppose that depends on a specific implementation of "close enough" is. =
I haven't looked at the specific code linux uses to implement this and "clo=
se enough" is fairly subjective and can be interpreted in different ways by=
different people. But even 1400 on, say, a 1420 MSS ICMP black hole is on=
e heck of a lot better than running no PMTUD at all and running at somethin=
g under 600 bytes.
> PS
>=20
> Your lengthy quotation means you don't see the point.
I am wondering where you got this magic 1400 value from. It should basical=
ly zero in on a number pretty close to the real path MSS in a few iteration=
s. Maybe that one specific implementation stops at the first successful va=
lue, but that isn't the way the recommendation is written.
Did I say it was "perfect"? No, but the notion that PMTUD is "broken" or "=
doesn't work" isn't exactly true. With the old mechanism, such a connectio=
n would simply hang or force people to turn off PMTUD completely. The new =
mechanism actually seems to perform rather well in the face of an ICMP blac=
k hole.
