legacy MTU of 1500 bytes

Posted Nov 4, 2022 23:15 UTC (Fri) by stephen.pollei (subscriber, #125364)
In reply to: legacy MTU of 1500 bytes by farnz
Parent article: Moving past TCP in the data center, part 1

I think that I'm in camp #3 "Split the difference". Some decrease in packet transmit latency seems good, but it isn't the only thing to optimize. I also remember 56k modems, where 1500 octets is 214 milliseconds worth of time.

In practice, Path MTU discovery can break in in interesting ways . People over block ICMP and perhaps a mechanism closer to what Cyberax suggested would be nice. With tunneling and MTU discovery having issues, CloudFlare at one point reduced their MTU to 1024 for ipv4 and 1280 for ipv6. It might have been nicer world in many ways if routers/switches supported 16k packets, but most people only used 12k normally. Extra 4k could be margin for tunneling and encapsulation. This is of course all IMHO.

legacy MTU of 1500 bytes

Posted Nov 5, 2022 9:47 UTC (Sat) by farnz (subscriber, #17727) [Link]

To an unfortunately large extent, broken Path MTU discovery is accepted on the Internet because you can pretty much assume that a 1280 byte MTU will be close enough to optimal that it makes no practical difference. If we had much larger MTUs - 6,000 bytes for 100M Ethernet, 24k for gig, 96k for 10G (yes, this needs jumbograms at the IP layer), WiFi probably at around 12k for 802.11n, and about 50k for 802.11ac, we'd have much more incentive to get PMTUD working well - the difference between 1280 bytes (minimum IPv6 frame size), and 12k for 802.11n is huge.