DomainBop
Dormant VPSB Pathogen
202.131.95.29 (Sydney).
Better peering to Asia (i.e. that doesn't go through Los Angeles/San Francisco) would be nice too...especially to Indonesia and China.
DigitalOcean to add Singapore Region by the end of January
- Thread starter joshuatly
- Start date
-
- Tags
- digitalocean
Better peering to Asia (i.e. that doesn't go through Los Angeles/San Francisco) would be nice too...especially to Indonesia and China.
Have a look at route announcements from AS1221, AS7474, AS7545, AS4739/4802 who are probably the largest AU ISPs in order.
The results I pasted were from the above providers looking glass options.
In terms of traffic out of AU to Asia, the submarine cable routes available result roughly in:
Perth to Singapore 50ms
Sydney to Hong Kong 110ms
Sydney to Japan 100ms
Between Perth (West coast) and Sydney (East coast) you'll see around 50ms.
A bigger issue is that the IP transit/peering interconnects don't necessarily follow the most ideal route.
Also the lowest latency path out of AU to Singapore, the SMW3 cable has the highest cost, lowest capacity, and least reliability and is on the side of Australia with the least population.
DO in Singapore should peering to the Equinix IX, that would be a decent option.
Another good option is to grab a circuit from Singapore to Hong Kong (around 30ms away) and peer at HKIX as a start.
Last edited by a moderator:
Wintereise
New Member
HKIX isn't really needed, they added a NTT pipe -- and NTT is very present at the HKIX.
At this stage, some eqix peering and maybe some local peering (private) will be all they should need to be better than 99% of the western companies attempting to run 'networks' here.
At this stage, some eqix peering and maybe some local peering (private) will be all they should need to be better than 99% of the western companies attempting to run 'networks' here.
Kris
New Member
Not really. Test from one of my Beijing test servers to their Singapore network. NTT America is great for anything but... Mainland access.
[root@cn2 ~]# traceroute 103.253.144.1
traceroute to 103.253.144.1 (103.253.144.1), 30 hops max, 60 byte packets
1 10.0.9.123 (10.0.9.123) 1.017 ms 0.962 ms 0.927 ms
2 115.47.0.254 (115.47.0.254) 4.661 ms 4.629 ms 4.598 ms
3 118.145.8.213 (118.145.8.213) 1.241 ms 2.122 ms 2.093 ms
4 60.195.255.201 (60.195.255.201) 1.330 ms 1.250 ms 1.191 ms
5 124.202.11.125 (124.202.11.125) 3.337 ms 3.312 ms 3.319 ms
6 202.99.1.213 (202.99.1.213) 2.830 ms 3.472 ms 3.308 ms
7 14.197.246.209 (14.197.246.209) 53.145 ms 46.274 ms 46.623 ms
8 221.4.0.134 (221.4.0.134) 45.793 ms 45.631 ms 45.416 ms
9 221.4.0.133 (221.4.0.133) 48.914 ms 49.061 ms 48.884 ms
10 120.80.2.45 (120.80.2.45) 48.241 ms 48.071 ms 47.883 ms
11 120.81.0.113 (120.81.0.113) 41.644 ms 41.520 ms 41.559 ms
12 219.158.99.93 (219.158.99.93) 45.363 ms 45.379 ms 219.158.99.109 (219.158.99.109) 51.755 ms
13 219.158.97.98 (219.158.97.98) 48.590 ms 47.074 ms 47.818 ms
14 219.158.97.118 (219.158.97.118) 61.913 ms 61.469 ms 61.332 ms
15 219.158.38.98 (219.158.38.98) 85.715 ms 85.005 ms 84.951 ms
16 as-0.r20.sngpsi02.sg.bb.gin.ntt.net (129.250.4.91) 171.996 ms 171.985 ms 158.326 ms
17 ae-1.r00.sngpsi02.sg.bb.gin.ntt.net (129.250.4.143) 148.362 ms 158.126 ms 148.701 ms
18 103.253.144.1 (103.253.144.1) 149.359 ms 150.845 ms 160.087 ms
That's on par with our mainland optimized network... Except from Beijing to San Jose.
Once I start seeing some actual mainland direct, be it Unicom or Telecom, this is far from an optimized network, and that's being nice. Will work great for anyone except mainland China at this point.
Wintereise
New Member
China is and has always been 'special,' I personally believe it's a dumb idea to optimize for CT/CU when they themselves cannot be bothered to give a hoot about you unless you buy direct bandwidth into CN.
Kris
New Member
Agreed, it does seem like a pay-to-play area. Sadly, if you want under 100ms, even close - you're going to have to go direct.
HKIX is never a bad touch either, but if you want mainland customers, and connectivity that's not beyond variable - buying some direct to the mainland is necessary.
Kris
New Member
BTW: http://www.hkix.net/hkix/participant.htm
NTT is there, but not there under 2914 for transit, but rather AS9293, so no HKIX for them, as currently peered.
Yeah correct, that's why I suggested it's probably good for DO to connect there locally via a tail from Singapore.
CT/CU you can either go direct at extortionate $ or use communities via your upstreams to try get whatever is working best on a given day.
CT/CU willingly congest links for long periods of time, and do other evil things like equal cost BGP load balancing over links with end points in different countries.
I wonder if mainland CN is really what DO are targeting for their client base, given that CN to US West coast, isn't that much higher latency than CN to SIN.
Last edited by a moderator:
Judging from DO IRC channel, about a half of DO customers are from India.But then again, routing to India isn't always ideal either.
Code:
HOST: lg-pune.prometeus.net Loss% Snt Last Avg Best Wrst StDev
1. hosted.by.prometeus.net 0.0% 10 0.1 0.1 0.1 0.2 0.0
2. 103.12.211.1 0.0% 10 0.4 1.0 0.4 6.3 1.8
3. 14.140.128.97.static-vsnl.net.in 0.0% 10 1.4 13.5 1.4 120.8 37.7
4. 172.29.250.33 0.0% 10 20.0 10.9 8.9 20.0 4.1
5. ix-0-100.tcore1.MLV-Mumbai.as6453.net 10.0% 10 14.1 14.0 13.9 14.1 0.0
6. if-9-5.tcore1.WYN-Marseille.as6453.net 0.0% 10 132.5 137.4 132.4 158.5 10.0
7. if-2-2.tcore2.WYN-Marseille.as6453.net 10.0% 10 125.4 126.5 125.2 131.2 2.4
8. if-9-2.tcore2.L78-London.as6453.net 0.0% 10 127.2 127.4 127.2 127.7 0.2
9. if-2-2.tcore1.L78-London.as6453.net 0.0% 10 126.9 126.9 125.5 130.3 1.3
10. if-17-2.tcore1.LDN-London.as6453.net 0.0% 10 127.2 127.4 127.2 128.2 0.4
11. 195.219.83.186 0.0% 10 130.8 130.8 130.6 131.3 0.2
12. ae-4.r22.londen03.uk.bb.gin.ntt.net 0.0% 10 130.5 132.9 130.3 155.7 8.0
13. p64-3-1-0.r21.sngpsi02.sg.bb.gin.ntt.n 10.0% 10 217.4 217.5 217.3 217.8 0.2
14. ae-6.r00.sngpsi02.sg.bb.gin.ntt.net 10.0% 10 231.3 231.3 231.0 231.4 0.1
15. 103.253.144.1 10.0% 10 220.6 223.5 218.9 235.3 6.6
Last edited by a moderator:
The problem with CU/CT is they don't null ddos. It happens all day. I find it pointless signing up with them.
Wintereise
New Member
Correct, not on the rr -- but there's enough private peering relationships with anyone worth peering with in HK. You'd be hard pressed to find tier one carriers who peer on the rr in Asia.
Why would they? This is APAC, and by denying you peering -- they force you to purchase transit.
This is basically APAC routing 101, more or less.
And secondly, the AS it's announcing out of hardly really matters, hknet is basically ntt.
You can verify connectivity to the university network (The Chinese University of Hong Kong -- cuhk.edu.hk) that hosts HKIX directly from NTT, if need be:
traceroute to 137.189.11.73 (137.189.11.73), 30 hops max, 40 byte packets
1 as-1.r21.tkokhk01.hk.bb.gin.ntt.net (129.250.4.115) 100.548 ms 52.122 ms 51.904 ms
MPLS Label=528131 CoS=0 TTL=1 S=0
MPLS Label=299952 CoS=0 TTL=1 S=1
2 as-1.r21.newthk02.hk.bb.gin.ntt.net (129.250.6.125) 57.939 ms 57.771 ms 52.691 ms
MPLS Label=299952 CoS=0 TTL=1 S=1
3 ae-2.r02.newthk02.hk.bb.gin.ntt.net (129.250.3.11) 54.093 ms 54.027 ms 53.549 ms
4 203.131.246.154 (203.131.246.154) 48.584 ms 48.762 ms 54.266 ms
5 115.160.187.102 (115.160.187.102) 53.279 ms 50.389 ms 56.510 ms
6 175.45.11.98 (175.45.11.98) 55.290 ms 55.262 ms 49.630 ms
7 203.188.118.81 (203.188.118.81) 51.103 ms 203.188.118.14 (203.188.118.14) 51.196 ms 203.188.118.10 (203.188.118.10) 56.079 ms
8 203.188.117.42 (203.188.117.42) 61.487 ms 72.918 ms 83.777 ms
9 137.189.192.250 (137.189.192.250) 57.347 ms 56.752 ms 57.090 ms
10 * * *
11 * * *
Being present there directly wouldn't really allow them any real benefits that having a subsidiary do it wouldn't bring. The reason behind this is probably because all HK companies with substantial traffic are REQUIRED by law to be present at the HKIX, and considering NTT runs hknet, they probably use the same set of ports for both usage.
Regardless though, relying on any sort of peering to even be remotely stable is not a mistake you want to make in Asia.
You want stable reachability to a network, you'll be forced to either peer privately -- or pay out the backside for expensive transit.
Last edited by a moderator:
This is extremely true with CU/CT. Basically, the only thing I would do with them is paid peering, and you pretty much have to be prepared to accept that there's going to be DDoS hitting your port with them.
NTT and Tata are both in Singapore, but clearly aren't peering or connected there, instead choosing to go to the UK and back. Madness, but not uncommon, it's not hard to stop trombone-ing traffic if you're a global IP provider.
Anyway, TATA are present at Equinix Singapore and HKIX, so my suggestions from earlier in the thread of DO peering at either of those locations would fix the route you have shown here.
Peering, it's not that hard
As I tried to say earlier, we're waiting on a large fiber maint before we can finish the installs of our other peering we have arranged. We have more coming soon.
I do appreciate the feedback, we were thinking along the same lines prior to the advice. Nice to see others view the area the same way.
I do appreciate the feedback, we were thinking along the same lines prior to the advice. Nice to see others view the area the same way.
Last edited by a moderator:
nunim
VPS Junkie
I apologize if it's been mentioned previously and I've missed it, but what is your relationship to DO?
Interesting thread... Happenings in Singapore market also influence Australia a bit but if the peering is poor and not utilising connectivity between Perth and Singapore it is not attractive to the Australian market.
If they peer with VOCUS (like basically every provider in Australia does) then connectivity from AU and NZ will become more attractive.
If they peer with VOCUS (like basically every provider in Australia does) then connectivity from AU and NZ will become more attractive.