If I could go back in time, I would replace fragmentation with in-flight truncation. The receiver sees the exact MTU and can communicate it back to the sender as needed.
router A <-> switch B <-> switch C <-> router D
router A <-> switch E <-> switch C <-> router D
It's a decent solution I think you just have the time backwards - it's something we should look to do as we move towards the future and the overhead of such logic is tiny to add to networking rather than something to wish we had in the past when even dumb hubs were expensively complicated.
This does leave one case unhandled though: you end up with a low MTU path at some point, things update so your traffic is going over a high MTU path, you still need to have some algorithm to discover this or the connection never recovers the performance.
If you want a world where you can rely on an L2 to have a way to handle the MTU mismatch then nothing is being solved by this other than the ability to say "fragmentation is not not in the current abstraction layer anymore, it's now an annoying problem on the layer below it instead" :).
The L2 MTU is fixed and known for every device on that same L2 network. The Internet is a network of networks; the reason we need to find the path MTU on the L3 network is that a single packet transits over several L2 networks, and while each L2 network has a single MTU, the L3 path can vary.
These underlying paths are not always static either, just because you have 9000 today doesn't mean when the path fails to a backup alternate tomorrow the MTU will be 9000. You have to get everyone involved on the internet to agree all links should now be 9000, now you can reliably set your router's outbound link to 9000 in all cases and rely on L3 fragmentation. Until someone wants to set their MTU to 12000 :). Even when I've had paid WAN transport with contracted MTU the MTU has lowered during carrier maintenance like firmware upgrades or unit replacements and I've had to call them up saying the MTU is broken because something like NFS servers will think they can statically set a known MTU on the path and it'll stay that way, a routed neighbor on the path would make the same error in this example.
The proposal is that in the case that the router is forwarding a packet which won't fit in the egress MTU, it truncates it, rather than drops it. Hopefully maybe with a truncated bit (maybe we can reuse the evil bit for this). If a peer receives a truncated packet, which it should know because either the evil bit is set, or the received length doesn't match the length in the IP header, that would be processed depending on the protocol. For TCP, the receiver should send a duplicate ack with a newly specified option that indicates the length of the truncated packet it received; then the other peer would know the maximum length packet it could send. For UDP, the truncated packet would probably need to be sent to the application and it could figure out how to notify the peer to send shorter packets (and perhaps process the received truncated packet).
Had this been specified in the before times, it would be reasonable to implement, and path mtu detection would work a lot better now. Some routers may still have been built that drop rather than truncate, but it's a lot more reasonable to send a smaller packet in some circumstances than to have the router fragment things (needs to send two packets sometimes instead of one) or to send a return packet (needs to create a packet and start it back through the routing process again).
Additionally, all of the signalling is in-band, which makes it harder to lose the MTU signals when (small) data is otherwise flowing.
router A <-> switch E <-> switch C <-> router D
Say router A and switch E have a 9000 byte MTU but switch C has an MTU of 1500 bytes. Router A gets a 12000 byte IP packet and sees to truncate the IP packet to 9000 bytes to be able to egress it to switch E, the designated path to its routed peer D. Switch E accepts this 9000 byte packet and bridges to switch C. Switch C only knows how to accept 1500 byte packets and so drops the 9000 byte packet. No truncated IP packet is ever delivered and the MTU is never learned.
This scenario, and a few others, are already noted in the RFC mentioned in the article https://datatracker.ietf.org/doc/html/rfc8899 as problems classically run into when trying to do PMTUD. Your browser based PMTUD test relies on these principles when it sends packets of various size, that's the only foolproof PMTUD method there is - truncating at egress on only routed hops does not provide foolproof IP delivery across the internet so cannot provide foolproof PMTUD.
Even when you can take the liberty to 100% guarantee A, C, E, and D will all support an MTU of 9000 bytes you can't guarantee nowhere else on your path across the internet will have the above issue on their switched paths between routers. Or that your packet won't go through a non-IP protocol tunnel as it goes through the internet and get dropped as too big in that encapsulation. Truncation is only 100% reliable when you're already 100% certain the real physical path across the internet can handle that size, which in practice requires knowing the real dynamic PMTU across multiple parties i.e. having PMTUD already.
I guess if you have this situation, you'd have the same problem we have today. Which is a too big packet gets dropped with no notification. But systems today don't tend to handle that well either. In practice today, usually people don't setup a mixed MTU broadcast domain, so I would expect a router between different networks to know the MTU of the next link. MTU (or really MRU) could have been put into ARP, if mixed MTU broadcast domains were expected, as well.
Otoh, there's a lot of situations where the router knows a route has a lower MTU, and could easily truncate, even if it can't easily fragment or drop and send an ICMP backwards. Truncation would be better than those two options.
And it might be easier to convince people to properly configure next hop MTU when it would enable truncation that would actually work. Instead of today where properly setting next hop MTU enables slightly earlier dropping of oversized packets because DF is almost (but not quite) universal and router fragmentation is disabled or rate limited and ICMP sending is disabled, rate limited, firewalled, or the router doesn't have a reasonable sending address.
In conclusion, while I ageee truncation wouldn't handle every case, it would handle every case where router based fragmentation could handle, and some more cases, and I think would have put us in a better place than we are today.
2. You at least get some information. Maybe half a packet is better than no packet.
3. You get an exact size limit of the entire path the packet took. Rather than just a "too big" of the first hop that wouldn't pass it.
Overall I think it is a pretty decent solution. Assuming that the IP header says the original size or similar so that the truncation can be easily detected.
I do see some flaws though:
1. Layered protocols would have to be more complex to deal with packet truncation. (Although I guess they could simply treat truncation the same as dropped to avoid extra complexity.)
2. Checksums at the end of a packet being dropped likely make the whole packet useless.
3. It may be better to get a quick rejection from a local router rather than the possibly far away peer.
IETF folks wouldn't like that much state in the IP protocol and it doesn't solve intermediate L2 loss (the real reason you have IP MTU differences) when switches are involved in the path though. That said, might make in interesting ICMP probing method.
All these advantages would come from truncation being "in-band", following the same path as the data packets, instead of being a special "out-of-band" message like ICMP packets are.
As for the flaws you listed:
1. The main complexity would come not from dealing with truncation itself (as you said, just treat it the same as a dropped packet), but from each protocol having to reflect the "truncated size" back to the original sender (like how ECN deals with marked packets).
2. The whole packet is not useless, the reason for truncating instead of turning it into an empty packet is to keep as much as possible of the higher layer headers. That is, most of the packet might be useless, but the higher layer headers at the start can be useful.
3. On the other hand, you might need several of these "quick" rejections before arriving at the ideal size.
ICMP does send the hop MTU, it's not just a "too big" signal. (But I do acknowledge that you're going for the PMTU in a single shot, and that's slightly neater.)
The fallback for anything (one way, lazy, filtered connection, truly anything) is you always have your minimum MTU where the protocol is guaranteed to work at a given size and if it's not the protocol knows the solution will need to lie outside itself. IPv4/IPv6 already have this today.
- Local UDP socket bind receives a 65k payload to deliver
- Local IP stack looks at where this is going to go, sees it'll be going out an interface with 1.5k MTU
- Local IP stack creates 44 IP fragments of 1.5k and a final smaller fragment (Note: For IPv6 the IP stack must instead default to the safe-by-standard value of 1280 byte MTU since dynamic discovery could not be performed)
- 1.5k packets get sent to the network
I can guarantee these steps because no NIC or router uses 64k L2 frames for this to be able to reach the gateway unfragmented.
From here we run into a bit of a real world problem vs a theoretical how fragmentation could be done problem. The article touches on why a little bit: intermediate routers can fragment if they want but they aren't required to (overwhelming often they actually won't) but even fewer routers will bother re-fragmenting (what would need to be done here, as you already have 1.5k fragments) as it's significantly messier still. Even Linux won't re-fragment IP packets when doing pure software forwarding!
My point is that IP fragmentation, as a method, gets packets through a network that would otherwise be truncated or dropped by other methods. It can also do it reasonably efficiently and conveniently, moreso than always assuming a worst case MTU at the application protocol layer.
I think what changes between methods is the use of fragmented packets to begin with? The whole premise is that IP fragmentation is bad because real world routers and firewalls don't support fragmentation properly. If fragmentation is deprecated, then wouldn't network stacks need to also start dropping oversized packets coming from user space applications?
If your route looks like this,
E_a -- MTU 1500 --> R_1 -- MTU 1200 --> R_2 -- MTU 1000 -> E_b
OP's suggestion is a single round trip: you emit a 1500 B packet, E_b receives a truncated 1000 B packet. E_b responds to E_a saying "that got truncated to 1000 B" and now E_a knows the PMTU, in a single shot. In an simple design, we can call the truncated packet "worthless" and force E_a to repeat it with the right PMTU, but it's still only too a single packet from E_a to elicit the right value for the PMTU from the network.