[NANOG] Microsoft.com PMTUD black hole?
Iljitsch van Beijnum
iljitsch at muada.com
Wed May 7 05:22:21 UTC 2008
On 6 mei 2008, at 23:48, Valdis.Kletnieks at vt.edu wrote:
>> A more common approach is to rewrite the MSS option in all TCP SYNs
>> with a smaller value so there won't be TCP segments large enough to
>> trigger the problem. AFAIK, all boxes that do PPPoE do this.
> And just the other day, you were saying:
>> Very few people out there use an MTU significantly below 1500
>> bytes. A
>> 1500-byte MTU will give you an _average_ packet size of ~1000 on
>> long-
>> lived TCP flows because there is one tiny ACK for every two full size
>> data segments.
Right. Why is that noteworthy?
I have a lot more to say about MTU issues in this draft about
negotating MTUs between two hosts/routers on a subnet so jumboframes
can be deployed without manual configuration:
http://www.ietf.org/internet-drafts/draft-van-beijnum-multi-mtu-02.txt
> Apparently, there's a *reason* why RFC1122, section 3.3.3 says:
> It is generally desirable to avoid local fragmentation and to
> choose EMTU_S low enough to avoid fragmentation in any gateway
> along the path. In the absence of actual knowledge of the
> minimum MTU along the path, the IP layer SHOULD use
> EMTU_S <= 576 whenever the destination address is not on a
> connected network, and otherwise use the connected network's
> MTU.
Tell it to Microsoft and their ICMP-filtering friends...
More information about the NANOG
mailing list