[NANOG] Microsoft.com PMTUD black hole?

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...