0

This is a follow-on to a question posted on stack overflow about whether it is possible to determine the one-way latency of a point to point connection without using externally synchronized clocks - turns out it isn't.

Now the question here is if such asymmetric latencies (where the trip time from A->B is materially different than the trip time B->A) is common in practice? Why?

What about in a typical data center LAN environment? What about across the internet backbone? What about across connections that have asymmetric bandwidth, such as many DSL, satellite or Cable connections?

Thanks!

4 Answers 4

3
  1. Yes.
  2. Because asymmetric routing (in it's many and varied forms) as well as asymmetric capacity and asymmetric load, are all common in practice.
  3. Not as common, but not unknown.
  4. Very common.
  5. Very, very common.
2
  • What are your numbers referring to? Mar 20, 2015 at 6:08
  • The five questions that were asked.
    – womble
    Mar 27, 2015 at 1:15
2

It's very common if you consider that incoming data may not take the same network route as outgoing to the same server. And you consider that you will nearly always be sharing the network with other network traffic.

QoS queues can add additional delays in either direction. Other traffic in either direction will affect response times.

Some people still have satellite links that use satellite for download, and modem for upload. It's a very different response time either way.

On a LAN, not so different latency...

So yes, it's very common in practice. Why did you ask?

1
  • I ask because if you want to optimize communication some particular grid/cloud structure of hosts, you'll be able to do it best if you know the one-way latencies of each link. The one-way latencies are difficult/impossible to calculate in practice, however, so you are left with round-trip times - so I'm curious whether 1/2 the RTT is in practice a good approximation to the one way latency.
    – BeeOnRope
    Dec 23, 2009 at 22:38
0

To expand on the "Why" question, your request from A -> Z might go:

A -> B -> F -> G -> H -> O -> Z

The next request might go:

A -> B -> E -> I -> J -> O -> Z

And the response may go:

Z -> O -> H -> I -> E -> C -> B -> A

All of the different hops along the way will have different latencies depending on load, outages, etc.

2
  • OK, but these just means that latency has some jitter and the whole process has some random deviation on each request - but this also imply that this asymmetry would remain relative constant (at least in sign) over time?
    – BeeOnRope
    Dec 23, 2009 at 20:49
  • Not really. The internet is incredibly fluid, 10 requests sent 0.1 of a second after each other might take 7 different routes to get there, and arrive in a completely different order than what you sent them. Do it 1 second later and they might arrive in a completely different order Dec 23, 2009 at 20:53
0

It seems to me that it would be possible to determine the one-way latency without the use of externally synchronized clocks if the time deviation between the two hosts is static\constant and is then factored in to the calculation.

3
  • Can you give details? If you can do it, you'd be able to show up the supposed "proof" on stackoverflow for this very question (link in OP).
    – BeeOnRope
    Dec 23, 2009 at 20:47
  • If you "mark" the time on the sender and then "mark" the time on the receiver and then calculate any time difference between the two into your latency measurements then you've measured your one-way latency without the use of an external clock, everything else being more or less equal. So for instance if the clock on the sender is 5ms faster than the time on the receiver and you send an ICMP packet from the sender at 00:00:00:00 and the receiver receives it at 00:00:00:20 then simply subtract 5 ms from the receiving end and you've got your one-way latency. Am I completely off-base?
    – joeqwerty
    Dec 23, 2009 at 23:23
  • I don't think you are completely off base, but the problem is that knowing that the clocks are out of sync by 5ms is the same really as having externally synchronized clocks (that just happen to have a fixed offset in practice). Since you can't calculate this offset dynamically (it has to be given to you as a fact), it doesn't seem useful in practice. Hope you were still waiting for a reply after 9 years :p
    – BeeOnRope
    Jun 1, 2018 at 5:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .