I can't agree with that statement. If upstream devices support larger than 1500 byte MTU, OR PTMU works correctly, then you are absolutely not going to "kill your network stack". At worst, (in the PMTU discovery phase) you'll see poor performance for a few moments while the MTU for the path is worked out, and then nothing but smooth sailing from then on.
> The point being is that for transferring data especially when responsiveness is important if not paramount utilizing the maximum potential frame size you can push without fragmentation would generally yield a poorer result in real world applications.
I'm not sure what you're saying here. Are you saying:
"If you configure your networking equipment to always wait to fill up a full L2 frame before sending it off, you'll harm perf on latency-sensitive applications."?
If you're not, would you be so kind as to rephrase your statement? I may be particularly dense today. :)
However, if you are, then that statement is pretty obvious. I expect that few people configure their networks to do that. However, I don't see what that has to do with the link's MTU. Just because you have a 9k+ MTU, doesn't mean that you have to transmit 9k of data at a time. :)
It absolutely does matter and is quite meaningful. :)
If you set your edge router's Internet-facing MTU to 9k, and the upstream equipment's MTU is smaller than that, then either your packets will be dropped, or PTMU Discovery will try to figure out the MTU of the path. (Better hope everyone along the path is correctly handling ICMP! :) )
> The only time you would want to use large packets is pretty much when you can have a buffer...
Or if you have high-volumes of data to move and want to dramatically increase the data:Ethernet_frame_boilerplate ratio. :)
> Also ... if you think about it the small packets are the most critical ones... [because they need to be dispatched as quickly as possible.]
Yes, but a larger MTU shouldn't affect this. Set whatever socket options are required to get those packets on their way as soon as they're created, and your system shouldn't wait to fill an Ethernet frame before sending that packet.