|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: [NANOG] Microsoft.com PMTUD black hole?
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 [email protected] http://mailman.nanog.org/mailman/listinfo/nanog
|