I'd add a fourth potential positive aspect of truncation: it could be implemented at full speed in the data path, instead of a separate process running on anoth

I'd add a fourth potential positive aspect of truncation: it could be implemented at full speed in the data path, instead of a separate process running on another CPU to generate, route, and send the ICMP packet. 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.