From: James (james@towardex.com)
Date: Wed Jul 14 2004 - 14:29:26 GMT-3
> I work for a company that has Servers on the Internet. It has been
> suggested that we reduce the MTU size on our Internet routers to 576.The
> rational is that some routers might not support a larger size,
> therefore, by picking this lowest common denominator, we insure that
> everyone will have a great experience. It has also been suggested that
> many ISP's will treat the smaller packets with a higher priority.
Ahhhhhhhh probably... not a good idea? :P
1500 is the usual number used by most end to end networks. There are many
networks out there who believe ICMP in its entirety is evil, and block the
whole protocol, thereby breaking PMTUD. I've found even fortune100 sites
blocking such on their front side load balancer / DMZ firewall.
Just route your office network behind a simple gre tunnel and watch some
web sites sites loading in pretty whacked style.
Many ISP's certainly don't run QoS or any congestion management, nevermind
WFQ. Smaller packets are not treated any better in most case, in fact they
are probably the first to be dropped often during congestion with no QoS.
ISP's are generally here to provide connectivity. Most ISPs for such reason
will simply add more capacity if they run out of bandwidth, where there is
no congestion to manage with QoS. Some smaller ones would probably employ
QoS anyways.
By picking the small MTU, that may not be optimal for your media/circuit
type, you will do nothing but give poor performance and random difficulties
accessing a number of sites due to PMTU breakage.
You may have noticed some people saying how they get better performance
by increasing MTU / packet size with GigE or higher speed links :)
>
> I do not think this makes sense, I have only seen problems with MTU,
> when using applications which set the don't fragment bit, and that was
> through a VPN. These were my thoughts:
>
> - The client and server should negotiate MTU size, so wouldn't it make
> more sense to reduce it on the server's themselves, if this is really a
> concern?
They do not negotiate the MTU size. They negotiate the TCP SMSS size, which
is the smallest maximum segment size. (See RFC879) Whichever host, whether
it be a client, or the server, has the smallest SMSS wins the negotiation.
So in other words, if you want to set a smaller MTU without causing problems,
you should set that smaller MTU size on every single host on your network,
so that proper MSS negotation can be performed between two hosts of the
end to end TCP session. If you simply set the smaller MTU on the intermediate
circuit itself on a router, both the client and server will negotiate with
the MSS size of the media they are directly connected to, in which usually
based on 1500 MTU size for Ethernet. So now you run into issue of the router
that has to deal with fat packets than what the link can handle.
>
> - Doesn't putting the same data in 3 packets instead of 1 reduce the
> header/payload ratio?
>
> - If a router cant support the MTU, won't it just fragment the packet?
> (most apps don't set the "no fragment" bit)
Many TCP applications set the "DF (Do not fragment) bit"
In such a case, the router in path is forced to drop the packet and send an
ICMP message back to the bigger-MTU-set host, as it is unauthorized to frag.
>
> Does anyone have experience or knowledge one-way or the other? I cant
> find anything in my searches that really bears this out.
This may give you a great example of problem. It is regarding a GRE tunnel,
but the source of the problem is due to difference in MTU size.
http://www.cisco.com/warp/public/105/56.html
-J
-- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:11:55 GMT-3