Is there have the way reducing latency using mikrotik?

RouterOS General
1

Hi,

There are several ways to reduce latency between China and US for network service.
1.Using CDN as like Google Cloud CDN. It will be additional charged.
2.If you are ISP, you can control PE router using by SDN. unfortunately, I’m not ISP.
3.Using VPN that would be low latency between two country. It is also additional charged.

So now is there have other ways to reduce latency between US and China network using by Mikrotik router?
I’m trying to search the best way how to reduce between long distanced networks without additional charged.
Because its would be effect almost network service.
I’ve got fiber network service between US and China but between two networks have latency approx. 100 ~ 123 ms.
So I hope to reduce that latency <40 ms.
If do you know the way of reduce latency better than upper cases, Please let me know so that I can try to configure it.

Thank you.

2

i think is a matter of physics:

distance between New York and Beijing is almost 11.000 kilometers in a straight line, at the speed of light on vacuum take almost 80ms to do the round trip.

i think you are very fortunate to get 100 to 120ms of latency between usa and china, i dont know any way to improve this situation

precisely that’s the reason of CDNs to exist, because the way to improve latency is to reduce the distance between client and server

3

In those scenarios, thinking about WAN optimization makes sense. Especially when transferred data sets are pretty repetitative.
Of course it’s not for free (actually pretty expensive) but we have fantastic results using Riverbed and Silver Peak - with a central SQL server (which is the main application to us) in the US and offices all around the world.
The experienced (not metered) performance in the remote locations is pretty close to sitting in the HQ.
SQL traffic is reduced by 98%, SMB by about 60…80% and Citrix about 50%.

-Chris

4

What is that, data compression?
There are a few data compression options in RouterOS itself.
Does this perform better?

5

No - all of the solutions being discussed (CDN, SQL server, etc) involve placing servers that are physically located closer to the users, and directing users in the region to use those servers instead of the ones in the USA.

The problem is that it is impossible to improve latency beyond the speed of light (think of Scotty’s famous line in Star Trek - “I canna change the laws of physics.”)

Using Google Earth, I found that the straight line distance between Beijing and NYC is 11,011,281 meters. (This line goes across the N pole by the way - real networks will take a longer path than this) The speed of light is 3x10^8 meters per second. This yields a one-way trip time of 0.0367 seconds, and a round trip time of 0.0734 seconds - 73.4 milliseconds. And this is a beam of light that just goes the distance and bounces off of a mirror.

Light goes slower in fiberoptic cable - I found a figure of 1.9986x10^8 meters per second (about 1/3 slower)

So using that figure, a fiber from Beijing to NYC that was as short as possible - going straight through the arctic ocean - would have a round trip latency of ~ 110ms
A more realistic path from Beijing to NYC via N Japan and Vancouver yields a distance of 12M meters. This distance gives a round trip time of 128ms.

I’d say that the network performance rea1ity is seeing is good and probably cannot be improved any more - certainly not by a factor of 40ms.
(unless they were to drill a fiber straight through the mantle of the earth and take the true straight-line distance, but then the fiber would probably melt, and it would certainly cost more than using a CDN)

And compression wouldn’t help latency - it can only help throughput. (to be fair, latency does affect throughput with TCP, it’s unclear whether this is the root issue that the original poster is trying to address)

EDIT: for giggles, I calculated the latency in fiber “straight through the earth” as being about 96 milliseconds. If you had a tube through the earth and it was a vacuum inside the tube, then shined a laser through THAT, then the round-trip latency would be 64ms. That’s the best that physics can offer without tachyons :wink:

6

Full ack, ZeroByte - and thanks for your elaboration on the speed of light which was fun to read.
In terms of Latency, throughput, optimization and tcp-wise latency having an impact on throughput I can just repeat my statement that we really have almost unbelievable results with WAN optimization over here - as a huge portion of the packets are completely handled locally.
Additionally, I’d like to mention that current WAN optimization platforms also take care of reordering packets and and packet loss - which all improves the ‘experienced’ lateny.
Also, connections are more robust due to the optimizers taking over connection handling…
They won’t be of much use in real-time applications really being dependent on latency - but to any other.

Cheers
-Chris

7

No, It’s not compression. Think of it as a pretty intelligent multi-protocol proxy. The closest comparable technology would be data deduplication on storages systems.
The data being really transmitted between the peers is just deltas to the cache content. In our case even Microsoft DFS deltas (which are known to be super-efficient) are still being optimized by up to 10%.
Additionally, the optimizers take over connection handling on the corresponding local sites and mitigate packet loss as well as reordering packets which arrive out of order - which all leads to a way better experienced performance.
-Chris

8

Interesting stuff - does the optimizer do something sneaky like using UDP across the long distance, and stuffing the payload back into TCP at the near end, cutting down the ACK times?
It’s obviously caching lots of stuff so that the cached content can be delivered in near-realtime. I can see how SQL queries would greatly benefit from such a thing. I once dealt with a customer complaint that a point of sale was not working because of the network - the wireless mesh introduced 40ms of latency to the LAN at some locations, (performing as specified by the mesh vendor, so it could not be improved). The remote terminals would perform 8 queries to the server for each click the user made - causing 320ms of lag in the application between click and response - which is quite noticeable and annoying to humans…

9

Optimizers really do a lot of sneaky stuff - as you mentioned, packing tcp payload in UDP packets for WAN-side transport being one of those tricks.
They also pool existing connections and a lot more which the vendors are not too chatty about… It’s quite a business :slight_smile:

Here’s a screenshot of one of our very typical SQL flows I made yesterday. (192.168.64.0/24 is our local network in Switzerland, 10.0.0.0/8 is at the US east coast where the SQL server lives)
The most interesting part obviously is the LAN- and WAN-packet count - as you correctly stated, this dramatically cuts down latency as all the LAN ACKs are handled locally. And this HAS an impact on latency :slight_smile:
The Screenshot is from a virtual SilverPeak appliance but other vendors (we also use riverbed for other locations) are comparable.
As We are drifting further away from MikroTik talk, I’d invite you to a chat by email if you like to get more information about this.
SQL-Flow-Stats.png
Cheers
-Chris