I already described the problem with assuming "the router must know the MTU of the link it's sending it on" implies guaranteed delivery across a switched path a

I already described the problem with assuming "the router must know the MTU of the link it's sending it on" implies guaranteed delivery across a switched path a comment higher in the chain: 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 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.