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!

Community
  • 1
BeeOnRope
  • 573
  • 3
  • 6
  • 12

4 Answers4

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.
womble
  • 96,255
  • 29
  • 175
  • 230
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?

hookenz
  • 14,472
  • 23
  • 88
  • 143
  • 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 '09 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.

Mark Henderson
  • 68,823
  • 31
  • 180
  • 259
  • 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 '09 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 – Mark Henderson Dec 23 '09 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.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • 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 '09 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 '09 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 01 '18 at 05:04