 |
| 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 |
>> 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...
_______________________________________________
NANOG mailing list
NANOG
http://mailman.nanog.org/mailman/listinfo/nanog
| Prev-Msg | Prev-Thread | Nanog | May-2008 | Next-Thread | Next-Msg |