Comment by cyberax | Hacker News Reader

Comment by cyberax | Hacker News Reader

Parent Full thread

There will be no larger MTU, this battle is lost. 1500 will live forever. If it makes you feel better, think about it as if Ethernet packets are just oversized ATM cells.

Solving PMTU problem would have required reifying the MTU to the IP layer. It could have been done like this:

1. Use a 16-bit field in the non-checksummed portion of the IP header. Initially this field is set to the MTU of the link that originates the packet.

2. Each router inspects this field, and sets it to the MTU of the next hop link, if it is lower than the MTU already in the packet. This will be cheap, as the field is not checksummed.

3. If the packet is bigger than the MTU of the next hop, just truncate it, and set a special bit somewhere in the packet header to indicate it. No need to recalculate the checksum either, the packet is going to be corrupt anyway.

4. The destination host gets the discovered MTU of the forward path, and sends it back to the originating host in the header of the next packet (in a checksummed part).

That's it. Easy, continuous MTU discovery, with robust handling of failures, that doesn't require any smarts from the routers (a comparator to update the MTU can be done in a few logical gates!).

Alas, nobody had the presence of mind to think about this back then.

It should be noted that pockets of jumbogram-in-the-wild exist. It's just normalised to clamp it to the point few people can exploit it.

For example, the NBN in Australia uses a 2000+ layer-2 frame and nothing like 500 bytes is consumed to mark the upper carrier. They COULD have gone higher than 1500 and I would be surprised if there arent customers using 1300 or less because of the ADSL configuration they brought over when they uplifted from a real modem.

A lot of people do 9000 in their filestore network. They know it works on the local segment. Reducing the forwarding burden in header-TCAM-routing by a factor of 5 is a significant win, if you have a lot of packets.

People continue to discuss mechanistic approaches to finding your MTU in the IETF but I think you're right: its 1500 or less pretty much forever unless somebody makes a move here for product differentiation reasons. Given the embedding of content inside the ISP or at the IX, I suspect it COULD happen, if e.g. Netflix said it was a better overall experience? The ISPs would do it.

Getting MTU=9000 to work is tricky even in a home network. I know, I spent several days setting it up.

And even then, I got slapped by WiFi. Its PHY MTU is limited to 2304 bytes, and that's a hard limit.

Even for the plain old wired Ethernet, I had to experiment a bit because the first multigig USB-C adapter didn't support Jumbo Frames.

Plenty of networks that use PPPoE over base network technology to connect to a "virtual" ISP implement at least mini jumbo frames. If you can set the MTU of the hardware to 1508 then the PPPoE connection runs at 1500.

If you don't do 2, you can have 3) if the packet is too big, just truncate it.

If the destination gets a packet that isn't as big as it says in the header, it was truncated, and the MTU is the size of the packet it received.

Even easier!

You still really should occasionally probe up, in case the path changed, but that's not very well done today either.

Yeah. You still need a way to reflect the discovered MTU value to the sender somehow, but this can be taken care of by higher-level protocols.

The approach obviously doesn't work at all for unidirectional protocols. This approach also doesn't work when there are multiple equal cost paths, but with different MTUs. Which used to be more common and now tends to only happen when changing link technologies. The original sender needs not just the discovered MTU, but the original header information that may have been used for flow hashing.

Reply on news.ycombinator.com