Re: [NANOG] Microsoft.com PMTUD black hole?

[Iljitsch van Beijnum <iljitsch () muada com>]

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