Does traceroute/MTR results in the same overall latency from src and dest direction and vice versa?

I was quite convinced that traceroute/MTR from A to B and B to A will have the same overall latency at the last hop as the reply would have been returning from the reverse direction, meaning i if take from A to B, the icmp will go from A to B and return from B to A (thru a different path not reflected in the current traceroute), so the latency will be the same from if i take from B to A, where the icmp will go from B to A and return from A to B thru the path in in the previous traceroute. This should then result in both icp going thru the same full path and thus should have the same latency.

However, my colleague is insistant that the latency seen is only for that path that is shown. And now i just want to make sure i'm not using the wrong concept all the while when troubleshooting.

Thank you.

On the Internet, there is no guarantee that A→B will follow the same path as B→A; and there no guarantee that two consecutive packets sent from A to B will follow the same path.

In other words, two packets A→B might go:

Packet 1: A→x→y→z→B
Packet 2: A→x→z→B

And similarly the return packets (B→A) needn’t follow the same path, they could be something different entirely; and they don’t have to follow the same path every time, either.

On a closed network (ie, one that you maintain), you could specify the routing in a deterministic (predictable) way to force the paths to be the same, but only when you control all intermediate routers between A and B.

While the asymmetric routing argument in the other answer is valid, it is not applicable to the ping/mtr/traceroute case.

The time it takes for the packet to travel from A to B usually is different than the time it takes for the packet to travel from B to A. But you almost never see those times individually.

ping, traceroute, mtr — all those tools measure the overall delay of the whole round trip, which is the sum of the time packet travels from A to B and the time reply travels from B to A. They send the packet and wait for the reply, and subtract the timestamp they sent the packet from the timestamp they saw the reply.

If you send PING from A to B, the PING REPLY has to travel from B to A. If you send PING from B to A, the PING REPLY has to travel from A to B. The addresses are the same when sending PING or PING REPLY from A to B, so the routing will be the same, and so is for the reverse direction. In both cases we have one packet from A to B and one packet from B to A and we measure the sum of their travel times. If we ping in other direction, the only thing changes is the order of addends, which doesn't matter.

The only valid cause of the difference might be if the intermediate systems treat PING and PING REPLY differently, e.g. impose different routing delays on them. This is very unusual and I wouldn't expect that. Nobody in their right mind will route PINGs from A to B along some path and PING REPLYs from A to B along other path. There is no valid point in setting up such detail in the configuration.

ICMP has the facility to measure the one-leg delay precisely, and that's TIMESTAMP and TIMESTAMP REPLY packets. It uses the mechanism similar to the NTP is using to synchronize clocks. The tools I mentioned, however, never use them, and nobody usually answers them.

Also, all the tools display the important bits of the latency distribution: average, minimum, maximum, and standard deviation. While successive packet latencies can differ substantially, distributions will be the same.

So, while your colleague might be correct in the sense the unidirectional delay "towards" is different from the delay "back", they are wrong in interpretation of what you see in the tools reports. Those reports should be the same distributions.