| ▲ | jeffbee 8 months ago | |||||||
The efficiency argument applies to private flows mostly. In terms of overall network traffic, the huge majority takes place between peers that share a local or private network. Internetworking as such has a relatively small share of total flows. So large frame sizes are beneficial in the context where they are also not problematic, and path MTU discovery is not beneficial in the context where it has many drawbacks. It seems as though the current state is pretty much optimal. | ||||||||
| ▲ | avidiax 8 months ago | parent [-] | |||||||
If you've ever tried to enable jumbo packets on your LAN, you'd soon learn that it causes lots of problems. First, every L2 "dumb" switch that doesn't support your jumbogram size just silently drops the packet, which is no good. Then, you have to figure out what size of jumbogram every device on your network supports, and select the minimum. In many cases, you'll have clients that don't support it at all. And I hope all your OSes support setting an MTU per route, and you enjoy setting special routes on all of your clients, since Path MTU discovery, even where it is enabled and supported, at the very least adds latency to every connection, if it even works at all. And god help you once you try to scale up your sweet jumbo frame solution. Plenty of routers have strict ICMP rate limits either imposed in software or hardware (because ICMP may be handled in an anemic CPU). So those ICMP fragmentation needed packets aren't reliably returned to your clients. It's even worse if your ISP doesn't block jumbograms outright. You will soon learn which of your ISPs peerings do or don't support jumbograms and whether they do or don't emit or forward ICMP. The only advisable way to use jumbo frames is if you are running a datacenter and you have a group of machines that can be properly configured for route-based MTU and that would benefit from jumbo frames, and every piece of hardware you buy is carefully specced to support it. | ||||||||
| ||||||||