0

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.

Jin
  • 1

2 Answers2

0

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.

fission
  • 3,601
  • 2
  • 21
  • 31
  • When you use ordinary ICMP PING and PING REPLY to measure the RTT and to determine the route, you don't know how much time was spent in PING travel and how much in PING REPLY. While those times might differ indeed, you don't know that detail. You only see the sum (by subtracting the timestamp you sent the packet from the timestamp you saw the reply). This is why it is called "*round trip* delay". Also, the delay can jitter even along the same route due to congestion, buffering, reordering and so on, but anyway that should be seen the same on both sides, because the round trip is the same. – Nikita Kipriyanov Mar 28 '23 at 05:38
  • There *are* [ICMP TIMESTAMP](https://networkengineering.stackexchange.com/questions/50511/when-is-timestamp-and-timestamp-reply-are-used-in-icmp-protocol) and TIMESTAMP REPLY, but those are rarely used. `mtr`, `traceroute` and `ping` never use them. Most sites never answer them. And, the similar mechanism is used in NTP to synchronize clocks, but that's UDP and nobody usually uses valid NTP packets to construct route traces. Also, even if TIMESTAMP was used, the idea of traceroute is to vary TTL and the reply we're waiting for is "TTL Exceeded" packet which still doesn't have a timestamp. – Nikita Kipriyanov Mar 28 '23 at 05:42
  • Tools like `mtr` and `traceroute` only measure the (return) latency for the particular probe packet that was sent to each intermediate hop _at that time it was sent_ – they can’t give the exact latency for every such path. You’re right about jitter, but again there is no guarantee of a _symmetric_ round-trip. So what you are measuring is the round-trip latency to each intermediate hop (and eventually to the final destination). But you can’t say that it will be necessarily equal on both outgoing and return trips, that is simply not true. – fission Mar 28 '23 at 07:46
  • The tools never measure *return* latency. They measure *total* latency, which is the sum send+return latency. You *can not possibly know* the return latency alone without using special techniques like ICMP TIMESTAMP or NTP. – Nikita Kipriyanov Mar 28 '23 at 08:10
  • I never said it was possible to know the return latency, only that it was not necessarily the same as the outbound latency (though it could be, and perhaps sometimes is by chance). – fission Mar 28 '23 at 08:17
  • And, again, what you are measuring is their *sum*. It doesn't matter from A to B you are measuring sum of the A→B+B→A or from B to A the sum B→A+A→B, the sums will be the same. It is those sums what is being measured and displayed in the mtr/ping/traceroute, so mtr/ping/traceroute will display the same thing running on either side, despite the fact that unidirectional latencies differ. – Nikita Kipriyanov Mar 28 '23 at 08:19
  • `mtr`, `ping`, and `traceroute` _may_ show the same result, but they may not; the path of a packet is not deterministic unless you are controlling all intermediate routers. There is no guarantee that even two sequential packets will follow the same route. – fission Mar 28 '23 at 08:23
  • Nobody guarantees nothing on the Internet. Nobody could do so. Everybody only cares of their own network (AS) and the SLA to their neighbors, which is insufficient to have strict guarantees. Does this invalidate the desire to know how long *on average* the packet travels forth and the reply back? – Nikita Kipriyanov Mar 28 '23 at 08:27
  • And no, they *may not* show different results. They *should* display the same. Because *on average* this will be the same. Despite, again, the fact that unidirectional latencies will be different, even "on average". According to the probability theory, the average of the sum of two independent is the the sum of averages. – Nikita Kipriyanov Mar 28 '23 at 08:29
  • As mentioned in the comment below, I agree that over a sufficiently long interval, a `ping` result would show a similar result from both sides. Only the destination ping in a `traceroute` or `mtr` would be expected to be very similar for both sides, since the intermediate hops (as viewed from either side) could be different. – fission Mar 28 '23 at 08:35
  • 1
    This is the valid point. But the question was specifically about that destination RTT ("at the last hop"). – Nikita Kipriyanov Mar 28 '23 at 08:40
  • 1
    Two successive pings from A to B are different to each other in the same way as ping A to B is different to ping from B to A; all of them are four packets sent, two from A to B and two from B to A, all in different instants of time. From the network standpoint, there is no difference. The validity of the comparison between ping A to B and B to A is the same as the validity of the comparison between two distinct pings from A to B. Their latencies will be different, their latency distributions will be the same. – Nikita Kipriyanov Mar 28 '23 at 08:44
  • Yes. Actually you may have noticed I have (>40 minutes ago) removed in my answer the bit about agreeing with the colleague, as I realized that there are conflicting remarks in the question and I wanted to avoid any doubt. – fission Mar 28 '23 at 08:45
  • No, I had not noticed that, thank you for pointing it out. – Nikita Kipriyanov Mar 28 '23 at 08:46
0

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.

Nikita Kipriyanov
  • 10,947
  • 2
  • 24
  • 45
  • I never said routing is the same. Instead, I said it could be not the same, and the delay A→B and B→A is almost never the same. But what we're measuring is the *sum* A→B + B→A and it *is* the same (as seen from the other side, B→A + A→B) . Read carefully. – Nikita Kipriyanov Mar 28 '23 at 08:08
  • You said “The addresses are the same, the routing will be the same”. Rather than demanding the reader to divine your intention, you should write clearly. – fission Mar 28 '23 at 08:10
  • I mean, it is the same routing for A→B PING packet as A→B PING REPLY packet. Sorry it it was unclear. Nobody routes PING and PING REPLY differently, the routing is based on only addresses, so these routes will be the same. Again, please, read carefully. – Nikita Kipriyanov Mar 28 '23 at 08:14
  • It may be the same, but of course two sequential packets don’t necessarily follow the same routing. In other words, if you have A ping B, and B ping A, the two round trip routes might not be the same. (To be honest, I find the repeated suggestion that I’m not reading your words to be discourteous at best, and I feel that that kind of remark is out of place here. Thanks.) – fission Mar 28 '23 at 08:19
  • If you insist on considering the individual packets differently, then the whole measuring is pointless. When we talk about measuring network latencies we talk about the latency distributions; this is why tools always display results in the form "avg/min/max/stdev". Yes, each individual packet might have different latency due to various factors, but this is washed out by the averaging. – Nikita Kipriyanov Mar 28 '23 at 08:24
  • I don’t see how measuring individual route latencies would be pointless, as this is often a useful network diagnostic. Yes, I agree that a ping average would be similar when viewed from both sides, as long as it’s taken over a sufficiently long interval. – fission Mar 28 '23 at 08:31
  • So where am I "not correct" (provided that I clarified the point about when routes are the same)? – Nikita Kipriyanov Mar 28 '23 at 08:46
  • My comment was made before your clarification and our subsequent discussion, so I am satisfied to remove it. – fission Mar 28 '23 at 08:53
  • Hi, thank you for the reply.Sorry, I may have been very vague with my question caused some confusion. What i was trying to asked is if for example i see an overall latency of 40ms from A to B in the MTR, should i technically also be seeing 40ms when the MTR is taken from B to A at the last hop, even though the path taken is different. I think Nikita have help me with this in that it should be the total time taken so it be the same whether taken from A to B or B to A – Jin Mar 29 '23 at 03:18
  • I understand that each probe may take a different path too, but i'm looking at a simplistic case where even though forward and reverse path are different, we assume that all probe follow the same path, just so i can get the concept right. – Jin Mar 29 '23 at 03:28