Let's say you send a ping from device 1 to device 2. The result would give you the RTT.
Theoretically speaking (because many variables are realistically in play), would the RTT be the same by pinging device 1 from device 2?
Let's say you send a ping from device 1 to device 2. The result would give you the RTT.
Theoretically speaking (because many variables are realistically in play), would the RTT be the same by pinging device 1 from device 2?
When things are working as intended the latency will be dominated by the speed of light. If the two endpoints are very close together (say in the same building), the processing time on any routers and switches on the path can be a larger contribution than the latency due to the speed of light.
These factors however will be the same as long as packets in both directions take the same path.
When there is more than one path the packets can take routers and switches will usually use Equal Cost Multi Path (ECMP) to decide which direction to send each packet. This generally uses a hash of selected header fields to choose the path. The header fields used will usually be a subset of:
Of these the first five will be the same regardless of which direction you are running the ping command from.
Flow label is likely to be different and could cause packets to take different routes. That field however only exists on IPv6 and not all routers will consider it when choosing a path.
ICMP doesn't have port numbers, so those fields would not be taken into account. A router could use the ID field instead, however it seems unlikely that such a special case would be implemented just for ICMP echo request/reply packets.
Thus overall it is unlikely for the packets to take different routes.
Another more likely reason to see different roundtrip times in the two directions is processing time on the two endpoints themselves. Receiving an echo request and responding with an echo reply is done by the kernel in every OS I know of and thus happens very quickly. But the ping command itself runs in user mode and will be subject to more latency if it is running on a busy machine. If the two machines are not equally loaded you can expect the ping command on the busy machine to see slightly higher roundtrip times for this reason.
Yes, to any significant precision RTT will always be the same. Distance traveled is the dominant factor in latency, and this is should always be the same as well. It is highly unusual to see any of the edge cases where distance traveled would not be the same, but a notable exception might be a change in load balancing. Some router can be using an advanced function to decide which route to put your traffic on and this can change between your two measurements. If there was Agent Based Adaptive Load Balancing, you might take a different route depending on how much traffic was using various available paths on your route. These are usually small differences, but in congestion or during different times of the day they can become significant.
Yes, even if each direction takes a complete different path, L3 devices (routers) don't take into account if the packet is an ICMP echo request as opposed to an ICMP echo reply, nor they take into account if the packet is a TCP SYN or a TCP SYN-ACK.
Just for illustration purposes, let's imagine that to go from A to B a packet has to go through 5 hops and it takes 12ms, then for a packet to go from B to A it has to go through 12 hops and a grand total of 22ms. The RTT measured on this scenario, regardless on which side you choose to start your measure, will be 34ms (12ms+22ms).