So you think you understand IP fragmentation?

On the one hand, ICMP Echo Responses are often rate limited. Sending all probes in a burst thus likely results in some missing responses because of the rate limit, not because of requests dropped due to too small PMTU. At least that was my experience back when I started writing the script. ;-)

If the largest probes in a "plateau search" are sent first, the first arriving probe (so not yet rate limited) has a good probability of being the largest probe fitting inside the PMTU. But even that may not be true if probes take different paths.

On the other hand, I do remember times when there was little bandwidth available and do not want to send one big burst as fast as possible. Some form of packet pacing is just more considerate with respect to other users of the network (perhaps I have too often encountered situations where adding packet pacing via some network device configuration shenanigans "solved" "network" problems of applications…). I am also comfortable waiting a bit for my manually triggered PMTUD to finish, which may not be the case for some VPN product user who might complain over long startup times.

Sending (1280+1400+1500=4180) bytes in one burst is still less than the TCP IW10 burst without pacing. (1280+1400+1500+8000+9000=21180) is even over the TCP IW10 maximum initial burst, but hopefully the larger packets would not get far, e.g., stay inside a data center. Together with a cooperating target (the other side of a VPN tunnel) this seems OK. (Using a 1280 bytes floor is a sign of the times, with more and more IPv6 all around. :-) )

I wrote my PMTUD script to work around a VPN missing a reliable built-in PMTUD mechanism. Therefore I use ICMP Echo although both rate and packet size limits are commonly encountered over the Internet. I do not need a special responder, just a server I want to reach via VPN that answers pings without size limit. As such I really like that you added PMTUD to the VPN product, and also put some thought into it. :-)