How to check which direction contributed more to latency in RTT?

[thestudent]

Hello, I know RTT in ping or traceroute is the total time it took from the packet was sent to the time it has received a response.

But what if I want to know what direction contributes more to the latency? I know that the path or route of the request can be different from the route of the reply.

How to check that? So I would know where to do routing changes when necessary. Sorry I have limited experience in troubleshooting and noticed that pinpointing often happens when it comes to these issues.

Anyone that can explain this in detail? Thank you in advance.

[balaji.bandi]

In most cases, this matters Voice or any sensitive application.

there is 3 most things that need to look at in terms of performance.

RTT = Round Trip Time; Time is taken for a signal to traverse a network from point X to point X.

DELAY = Time taken for a signal to traverse a network from point X to point Y

LATENCY =  Delay or Lag in network communications,  This can cause many reasons hardware,  network issue  or any congestion in the Link.

If you have more than 1 Link you can use IP SLA and route the traffic based on the results.

If you do not have more Links, then you need to Looks QoS to make Priority traffic based on the requirement.

[thestudent]

Thanks Balaji,

How do I measure that? For example the DELAY, where can I see that information when troubleshooting links? Do you know any tools?

[balaji.bandi]

some examples help you depends on the device : (but this give you fare idea)

https://www.cisco.com/c/en/us/support/docs/availability/high-availability/24121-saa.html

https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/5125-delay-details.html

[Joseph W. Doherty]

In the past, one method I've used to try to identify a particular path, or paths, have a problem, in one particular direction, has been to use source routing, usually the "loose" variant (as the strict variant often does not support the number of hops the packet will transit).

Unfortunately, security best practices generally disable this feature on network routers.

In theory, a two end (i.e. running on both "ends") network application could timestamp (possibly needing NTP on both ends) outgoing packets, and the other side note how long it takes to receive them.  Such an application could determine which direction has more latency (and loss) then the other.  Of course, you would need a host on both "ends" to run such an application.  Also, unfortunately, I don't know of any existing test tools that support this, but some may.  (Also in theory, not all that difficult to create.)

BTW, whenever using ping or traceroute for RTT, keep in mind both can be highly inaccurate because RTT also includes host response time, and since network devices (and other hosts) usually treat such requests with low priority, RTT can give an inaccurate "picture" of network transit conditions.  (This is why Cisco's "special" SLA responders inform requestor how long host "sat" on request.)