I know this is outside the scope of “North America”, but has anyone else been fielding more issues related to network health/congestion in the middle east, specifically Israel?
Our users in Israel are primarily served from India-based resources (AWS/Azure), both of which have cloud capacity issues in India that I’m aware of.
Also, the majority of our users in Israel that have been reporting slowness seem to be mostly behind the ISP Bezeq. If we force them to route to Ireland (which is technically farther away form a latency standpoint) things are much better, so I’m wondering if just Bezeq (or everyone in Israel) is just experiencing 3rd party-related network congestion to Mumbai.
Thanks
John
Hey John,
Do you have some background information about how Dublin is “technically farther away” than Mumbai? Is the latency actually better in the middle of the night? I’m genuinely curious, and I’ll explain the reason why… 
The shortest submarine route to Mumbai would probably be Mednautilus to Greece, hope you can crossconnect to AAE-1 there, and then through Egypt, around the Arabian Peninsula, to Mumbai. All in all ~7800km if not more, and that’s a pretty uncommon path - you may have to go all the way to Italy or even Marseille to do the crossconnect.
Compared to using let’s say Jonah to connect to Italy for ~2300km, terrestrial to the western UK via the Channel tunnel for another ~2500km, take UK to Ireland over let’s say Solas for ~230km, and the last stretch to Dublin for ~180km. All in all ~5200km, and that’s all pretty common routing for the Internet.
Then the last option could be a terrestrial path straight through the Arabian peninsula and using a submarine cable for the last stretch to Mumbai, which may technically be the shortest distance with ~4500km covered… but let’s just say that there is a reason why Google’s Blue-Raman cable will be a very impressive achievement if/when it goes live: https://www.haaretz.com/israel-news/business/.premium-israel-to-play-key-role-in-giant-google-fiber-optic-cable-project-1.8764470
Best regards,
Martijn
Most (if not all) of Israel’s capacity is served from Europe. There is no real reason to serve users in Israel from India… You should most likely be using instances in Frankfurt or London for best results.
John,
As others have mentioned you should be going to Europe we have a POP in Rosh Hayain, IL and in Nicosia, CY. Both POP’s backup to AWS Ireland. Almost all of your traffic in IL is going to go through Western Europe so it makes no sense to send it to India. Israel does not have any peering with its neighbors.
I just did some tests from Bezeq in Petah Tiqwa
AWS Ireland
[root@cust-219-83-123 ~]# ping 3.248.0.0
PING 3.248.0.0 (3.248.0.0) 56(84) bytes of data.
64 bytes from 3.248.0.0: icmp_seq=1 ttl=223 time=69.0 ms
64 bytes from 3.248.0.0: icmp_seq=2 ttl=223 time=69.1 ms
^C
AWS Virginia
[root@cust-219-83-123 ~]# ping 3.80.0.0
PING 3.80.0.0 (3.80.0.0) 56(84) bytes of data.
64 bytes from 3.80.0.0: icmp_seq=1 ttl=238 time=149 ms
64 bytes from 3.80.0.0: icmp_seq=2 ttl=238 time=149 ms
^C
AWS Mumbai
[root@cust-219-83-123 ~]# ping 3.6.0.0
PING 3.6.0.0 (3.6.0.0) 56(84) bytes of data.
64 bytes from 3.6.0.0: icmp_seq=1 ttl=233 time=168 ms
64 bytes from 3.6.0.0: icmp_seq=2 ttl=233 time=168 ms
^C
AWS Milan
[root@cust-219-83-123 ~]# ping 15.161.0.254
PING 15.161.0.254 (15.161.0.254) 56(84) bytes of data.
64 bytes from 15.161.0.254: icmp_seq=1 ttl=239 time=58.5 ms
64 bytes from 15.161.0.254: icmp_seq=2 ttl=239 time=58.4 ms
^C
AWS London
[root@cust-219-83-123 ~]# ping 3.8.0.0
PING 3.8.0.0 (3.8.0.0) 56(84) bytes of data.
64 bytes from 3.8.0.0: icmp_seq=1 ttl=229 time=57.2 ms
64 bytes from 3.8.0.0: icmp_seq=2 ttl=229 time=57.2 ms
^C
AWS Frankfurt
[root@cust-219-83-123 ~]# ping 3.120.0.0
PING 3.120.0.0 (3.120.0.0) 56(84) bytes of data.
64 bytes from 3.120.0.0: icmp_seq=1 ttl=235 time=50.7 ms
64 bytes from 3.120.0.0: icmp_seq=2 ttl=235 time=50.7 ms
^C
It seems like you’re better off going to the US over going to Mumbai!
Yeah, this is bad default GeoDNS logic. I’m overriding Israel now to use Europe now, and things are much better.
-John