 |
| Prev-20 | Home | Next-20 |
| Prev-20 | Home | Next-20 |
| Prev-Msg | Prev-Thread | Nanog | May-2008 | Next-Thread | Next-Msg |
| Subject: | Re: Microsoft.com PMTUD black hole? |
| Group: | Nanog |
| From: | Iljitsch van Beijnum |
| Date: | 7 May 2008 |
> 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
http://mailman.nanog.org/mailman/listinfo/nanog
| Prev-Msg | Prev-Thread | Nanog | May-2008 | Next-Thread | Next-Msg |