thiamwah
asked on
Internet Web Server - What is the optimized MTU?
hi,
I have a Linux Web Server in a hosting facility connected to the Internet on multiple T1/E1 leased lines. I was reading about MTU / MSS and fragmentation, etc.
Since my web server services all types of clients on the net e.g dial-ups, ISDNs, DSLs, corporate LANs, etc..
wouldn't the default Ethernet MTU of 1500 bytes cause datagrams to be fragmented when the IP datagrams are delivered to e.g. dial-up clients with MTU of 576 bytes ?
This would result in slower delivery, but if the Don't Fragment (DF) flag was instead checked, it would also cause problems if the ICMP packets could not make it back to the server?
How is this handled in the "real-world" Internet?
And what is the optimized settings for the MTU of my web server..??
Please advice... Thxs
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I'll go along with the use of default, to keep it simple. Unless you know otherwise for specific platforms.
I want to believe either highest or lowest value can add value, depending on environment, and that the parameter max ought to be a little higher than most set it, but it depends on vendor, mixture, and whether or not headers are counted.
But real world not that way. I've seen where people have reconfigured their client's MTU to reduce jobs from hours to minutes, one going higher, another lower. Go figure. Any case, it is one of those tuning things that it helps to experience first hand. One hopes default accounts for that.
A related client example is that at least one shrinkwrap vendor for remote management had one version tuned quite well for a Netware environment, but it was slow for their TCP/IP upgrade, so they changed the parameter (impacting Netware).
What you may want to check out if curious is MTU for token Ring vs ethernet. Most now use the ethernet max (lower). MSS is typically MTU minus TCP&IP 40 byte header. Connections are further discussed in RFC 1191. Many find easier reading, in general, through certain publishers like O'Reilly and New Riders.
The tuning game of parameters can vary based on servers, platforms and router capability. Older systems are more likely to provide better performance with the lower values than newer systems.
> dial-up clients with MTU of 576 bytes ?
What if.. WAN has MTU at 520 (with 500 data)? IP spec is 576 min datagram. Since size can be negotiable, rule of thumb is that the better overall is highest value that is permitted for most of the paths.
On significance, we had server moved to route via gigabit, a dramatic speed increase. Application that had taken minutes began to take hours. Adjusting MTU in Windoze restored the response time for the application. So you are correct in assuming the parameters can impact performance.
IMO, best overall is to go with defaults like this unless you know otherwise. You can always set up tests of alternatives, for specific situations, and reconfigure accordingly. Generally, it runs better at higher values, and better at values that are set the same for the most communicators.
I want to believe either highest or lowest value can add value, depending on environment, and that the parameter max ought to be a little higher than most set it, but it depends on vendor, mixture, and whether or not headers are counted.
But real world not that way. I've seen where people have reconfigured their client's MTU to reduce jobs from hours to minutes, one going higher, another lower. Go figure. Any case, it is one of those tuning things that it helps to experience first hand. One hopes default accounts for that.
A related client example is that at least one shrinkwrap vendor for remote management had one version tuned quite well for a Netware environment, but it was slow for their TCP/IP upgrade, so they changed the parameter (impacting Netware).
What you may want to check out if curious is MTU for token Ring vs ethernet. Most now use the ethernet max (lower). MSS is typically MTU minus TCP&IP 40 byte header. Connections are further discussed in RFC 1191. Many find easier reading, in general, through certain publishers like O'Reilly and New Riders.
The tuning game of parameters can vary based on servers, platforms and router capability. Older systems are more likely to provide better performance with the lower values than newer systems.
> dial-up clients with MTU of 576 bytes ?
What if.. WAN has MTU at 520 (with 500 data)? IP spec is 576 min datagram. Since size can be negotiable, rule of thumb is that the better overall is highest value that is permitted for most of the paths.
On significance, we had server moved to route via gigabit, a dramatic speed increase. Application that had taken minutes began to take hours. Adjusting MTU in Windoze restored the response time for the application. So you are correct in assuming the parameters can impact performance.
IMO, best overall is to go with defaults like this unless you know otherwise. You can always set up tests of alternatives, for specific situations, and reconfigure accordingly. Generally, it runs better at higher values, and better at values that are set the same for the most communicators.
> And what is the optimized settings for the MTU of my web server..??
Interesting side question... for those with many servers, and load balancing implemented, would they try to specialize by having tuned one server with one MTU, another with another...
Interesting side question... for those with many servers, and load balancing implemented, would they try to specialize by having tuned one server with one MTU, another with another...
ASKER
>>
I have never personally configured it, but I know that many web site administrators use path MTU. This
is a method of determining the largest MTU ...
>>
I read up on Path MTU. Pretty cool :)
Is path MTU negotiated for every Internet client that attempts to connect to my server ? Wouldn't that add quite a bit of overhead to the whole process..??
I have never personally configured it, but I know that many web site administrators use path MTU. This
is a method of determining the largest MTU ...
>>
I read up on Path MTU. Pretty cool :)
Is path MTU negotiated for every Internet client that attempts to connect to my server ? Wouldn't that add quite a bit of overhead to the whole process..??
No, Path MTU is -- right or wrong -- considered to be a security problem on the internet and it may or may not help you because all routers between you and the requestor would need to be configured to support it and I can pretty much guarantee that they won't.
As sunbow points out, you can dramatically alter performance using this parameter under certain conditions. But GENERALLY those "conditions" don't exist in a public network . . . conditions such as predictability of packet size (for example if 99.9% of the volume of your traffic was in 128byte chunks -- like my network -- altering MTU would have no effect. On the other hand if you have lots of huge web pages to dump to the internet, you'd see performance improvements with larger packet sizes. But this is so general that it's almost useless.
Lots of serious people put protocol analyzers at different points in their network to determine just what the packet size mix actually is and then adjust the MTU accordingly.
Ethernet default MTU is 1500 bytes on most operating systems including NT. One interesting fact is that NT uses a default MTU of 576 bytes if the destination network is different from the source network. In other words when I FTP a file from 10.1.1.1 to 10.1.1.2 an MTU of 1500 bytes is used. When I FTP a file from 10.1.1.1 to 192.168.1.2 the MTU gets set to 576 bytes because Microsoft decided that if you are doing something like this you must be traversing the internet and they want to be good internet non-packet-fragmenting neighbors. But if 10.1.1.1 is on a 100mbit network segment attatched to a router with an ATM card with a network address of 192.168.1.1 then a 576 byte MTU is pretty inefficient . . . for FTP anyway.
Good luck.
Steve
As sunbow points out, you can dramatically alter performance using this parameter under certain conditions. But GENERALLY those "conditions" don't exist in a public network . . . conditions such as predictability of packet size (for example if 99.9% of the volume of your traffic was in 128byte chunks -- like my network -- altering MTU would have no effect. On the other hand if you have lots of huge web pages to dump to the internet, you'd see performance improvements with larger packet sizes. But this is so general that it's almost useless.
Lots of serious people put protocol analyzers at different points in their network to determine just what the packet size mix actually is and then adjust the MTU accordingly.
Ethernet default MTU is 1500 bytes on most operating systems including NT. One interesting fact is that NT uses a default MTU of 576 bytes if the destination network is different from the source network. In other words when I FTP a file from 10.1.1.1 to 10.1.1.2 an MTU of 1500 bytes is used. When I FTP a file from 10.1.1.1 to 192.168.1.2 the MTU gets set to 576 bytes because Microsoft decided that if you are doing something like this you must be traversing the internet and they want to be good internet non-packet-fragmenting neighbors. But if 10.1.1.1 is on a 100mbit network segment attatched to a router with an ATM card with a network address of 192.168.1.1 then a 576 byte MTU is pretty inefficient . . . for FTP anyway.
Good luck.
Steve
"No" is my answer to your question about whether every connection inbound on your server does path MTU discovery. And MTU is NOT negotiated, path MTU simply reports back to the originator what the smallest MTU for the path is and your machine sets MTU for that value . . . I suppose that is technically some form of negotiation . . . But negotiation to me means that all parties involved agree on a value, whereas path MTU discovery simply finds out what's there and reports back.
Steve
Steve
[closed mar 6th]
I will say though that this opens up a large can of worms, as some ICMP packets will get blocked by customer firewalls and you will need to open up certain ICMP types to your web server through your firewall. Many times, this will cause failed sessions and irate customers. However it is still used fairly often these days.
Other than that, I would stick with 1500.