[Suppafly]

>Not only is it contingent on your intermediaries actually responding to your packet with the diagnostic information you want, it assumes that the diagnostic response will also be able to get back to you.

Isn't most of the diagnostic information just stuff that's part of TCP/IP anyway?

[FxChiP]

The diagnostic information is really two things: (1) whether you get the packet back to begin with and (2) where it comes from and the ICMP state, which, yeah, is stuff that's part of IP anyway. The point was that the response is also a packet, and subject to all the same potential issues as the packet it's responding to.

[Suppafly]

>The point was that the response is also a packet

Sure, which is why it's useful. If the response doesn't get back it's not a reliable route. It seems like you're saying tracert is bad because of some sort of circular reasoning where you've decided it's bad so it's bad.

[FxChiP]

> If the response doesn't get back it's not a reliable route.

It's not a reliable route specifically for the response packet from the intermediary to the original host -- and that might be because it gets routed out the wrong interface. It could also be because the intermediary doesn't send anything at all (which would therefore mean nothing about the validity of the route either way).

> It seems like you're saying tracert is bad because of some sort of circular reasoning where you've decided it's bad so it's bad.

I didn't even say tracert was bad. I even said on simple, straightforward routes where everything cooperates and everything aligns properly, it's great. There are just lots of external factors to keep in mind that have nothing to do with the end user that might inadvertently affect its usefulness.