[150285] in North American Network Operators' Group
Re: Common operational misconceptions
daemon@ATHENA.MIT.EDU (Masataka Ohta)
Mon Feb 20 19:19:20 2012
Date: Tue, 21 Feb 2012 09:16:53 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
To: George Bonser <gbonser@seven.com>
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD7264@RWC-MBX1.corp.seven.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
George Bonser wrote:
> I am saying that MTU probing works just fine, even with a
> link in between that has a shorter MTU and doesn't pass
> ICMP.
And I have been saying your statement is unfounded.
> I actually have one of those.
I can't see any.
> It actively probes with packets of varying sizes and learns
> what the path MTU is.
First, it sets eff_pmtu to 1400B. OK?
> It does not rely on ICMP. Again, it actively probes with
> varying sizes of packets until it believes it has
> "converged".
> The initial value for search_high SHOULD be the largest possible
> packet that might be supported by the flow. This may be limited by
> the local interface MTU, by an explicit protocol mechanism such as
> the TCP MSS option,
OK, so, even with local MTU of 7500B and without ICMP PTB, if
local MTU of your peer is 1500B, TCP MSS makes search_high
1500B.
As eff_pmtu of 1400B is close enough to search_high, you are
done.
Eff_pmtu of 1400B will be used forever with no probe packets
sent.
> The timer for Linux is 5 minute by default but you can change it.
Timer timeouts do not affect TCP MSS.
Masataka Ohta
PS
Your lengthy quotation means you don't see the point.
