There's no guarantees on path during a trace; after all, a connection could drop or come up during a trace, and routing may change as a result. We're packet switched, not circuit switched, so there's nothing out of spec if you route differently.
However, tcp is sensitive to getting packets out of order, and most multipacket udp applications aren't a big fan either. So it's common to ensure a packet with a given 5-tuple {ip dest, ip source, protocol, protocol port dest, port source} will route the same, including traveling over the same port in a multi-port bundle, unless that next hop goes down or a better next hop comes up.
That said, many traceroute implementations default to using a new port for each probe, and depending on the networks between you and what you're probing, you might see a variety of paths in a single short probe. When that happens, you really don't get much information.
Of course, the return path for the packets is likely to be different and isn't easy to know; if you control both ends, you obviously can; and if the destination network has a good looking glass, you can get some idea, but detailed traces aren't going to happen.
All that said, parts of the rant are accurate. Routers and hosts don't have to participate and many don't or are rate limited. Intermediate latency is often not very helpful. Where a trace ends only tells you were the trace ends, not where the packets left the network (possibly at the destination). Having useful diagnostic information doesn't help if you can't get in touch with someone who will use the information to fix the problem.
Being able to trace from multiple vantage points helps make sense of things.
If you're experiencing intermittent behavior like some tcp connections between two hosts work great and some don't, and most of the network involved participates in tracing and you have a good contact, you can do specific tracing and narrow down the routers they need to check to find the problem; sometimes that helps time to resolution a lot.
If you don't have a cooperative network, it's better to invest in making multiple connections and using the best one as measured; because that gives you agency to 'fix' network problems.
- Don't block ICMP: Echo Request and Echo Reply, Fragmentation Needed (IPv4) / Packet Too Big (IPv6), Time Exceeded, and only within the boundary allow NDP and SLAAC (IPv6)
But presumably none of that helps solve for what traceroute is used to help diagnose.
"ICMP: The Good, the Bad, and the Ugly" (2016) https://blog.securityevaluators.com/icmp-the-good-the-bad-an... ; blocking ICMP mitigates {Ping sweep, Ping flood, ICMP tunneling, Forged ICMP redirects,} but breaks {Path MTU discovery (PMTUD), TTL, ICMP Redirect}
What I block or don't for ICMP doesn't much matter when I'm tracerouting through networks I don't control,which is nearly all of them. Yeah, if I block the returns from my probes, I won't get useful results for traces to pretty much anywhere, but that should solve itself.
However, tcp is sensitive to getting packets out of order, and most multipacket udp applications aren't a big fan either. So it's common to ensure a packet with a given 5-tuple {ip dest, ip source, protocol, protocol port dest, port source} will route the same, including traveling over the same port in a multi-port bundle, unless that next hop goes down or a better next hop comes up.
That said, many traceroute implementations default to using a new port for each probe, and depending on the networks between you and what you're probing, you might see a variety of paths in a single short probe. When that happens, you really don't get much information.
Of course, the return path for the packets is likely to be different and isn't easy to know; if you control both ends, you obviously can; and if the destination network has a good looking glass, you can get some idea, but detailed traces aren't going to happen.
All that said, parts of the rant are accurate. Routers and hosts don't have to participate and many don't or are rate limited. Intermediate latency is often not very helpful. Where a trace ends only tells you were the trace ends, not where the packets left the network (possibly at the destination). Having useful diagnostic information doesn't help if you can't get in touch with someone who will use the information to fix the problem.
Being able to trace from multiple vantage points helps make sense of things.
If you're experiencing intermittent behavior like some tcp connections between two hosts work great and some don't, and most of the network involved participates in tracing and you have a good contact, you can do specific tracing and narrow down the routers they need to check to find the problem; sometimes that helps time to resolution a lot.
If you don't have a cooperative network, it's better to invest in making multiple connections and using the best one as measured; because that gives you agency to 'fix' network problems.