[104329] in North American Network Operators' Group
Re: [NANOG] Microsoft.com PMTUD black hole?
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Wed May 7 01:29:55 2008
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Nathan Anderson/FSR <nathana@fsr.com>
In-Reply-To: <4820CD9F.1020308@fsr.com>
Date: Wed, 7 May 2008 07:29:41 +0200
Cc: nanog@merit.edu
Errors-To: nanog-bounces@nanog.org
On 6 mei 2008, at 23:29, Nathan Anderson/FSR wrote:
> Now, although that makes sense, in order to avoid issues like the
> one we
> are facing with Microsoft, would it not make _more_ sense for the
> stack
> to look at the PMTU cache first, and then adjust its own MSS just for
> connections to that one host? Maybe even send out an MTU - 40 ICMP
> packet to the host that we want to build a TCP connection with FIRST
> to
> get an ICMP type 3 code 4 response from the router in-between with the
> smaller MTU?
No. This would add significant delay because you'd have to give the
other side enough time to respond to the large packet (also sending a
large packet on something like GPRS/EDGE is a waste of bandwidth and
battery power) while if there is ICMP filtering, there won't be a
response, which is exactly the reason why we're in this bind in the
first place (along with the stupid idea that DF should be set for ALL
packets rather than just once in a while).
And adjusting the MSS based on ephemeral information is the wrong
thing to do in the first place. The path MTU can vary. Once you've
advertised a small MSS you can never increase it.
It is incredibly unprofessional that people enable PMTUD, then break
it and require the rest of the world to implement workarounds. Either
use PMTUD properly by accepting the ICMP messages or turn PMTUD off.
_______________________________________________
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog
