Those routers are in California. IP locators are giving you registration data, not physical location of the router. If the traffic was actually traversing HKG you would see significantly higher end-to-end latency (13000 mile path vs. 6500 mile path at ~120000 miles per second gives you 108ms vs 216ms RTT).

As for the two different Vodafone UFB services giving different performances, one is clearly on the legacy TelstraClear network with its associated upstream connectivity and one is on the Vodafone network with its separate upstream connectivity. The two networks are not really merged at all; thus the performance is significantly different.

^ Auckland-->San Jose via London and for Battlefield Auckland-->Sydney via Tokyo... seems your classic tier-1 internet routing as they own all the fibre optic cables they don't care about efficient routes.

Although interesting to note it's affecting gaming services, they often employ DDoS mitigation techniques some of which can result in suboptimal routing especially amongst your non-open-peering & tier-1 providers.

yitz: ^ Auckland-->San Jose via London and for Battlefield Auckland-->Sydney via Tokyo... seems your classic tier-1 internet routing as they own all the fibre optic cables they don't care about efficient routes.

Where do you see it going via London? Auckland to London is close to 300ms on a good day, which would make Auckland - London - San Jose in excess of 500ms. This looks like a congested interface, or a sub-optimal return path - the outbound path looks fine.

Historical DNS PTR records show ulco.telstraglobal.net for that 202.40.148.50 hop for which "ulco" is some PoP in the UK I believe.Not sure what's happened to telstraglobal.net DNS, seems they have rate limited it so intermittent resolution/caching.

The return route is fine (you can probably check at lg.wargaming.net), so RTT is effectively a round trip to UK since UK goes via San Jose for most anyway.

If you lookup 192.184.12.13 and 208.64.123.97 they are the IPs for a DDoS mitigation provider, maybe the Vodafone UFB network has been considered amongst sources of the DDoS?

DDoS mitigation and filtering will always mean a crappy route as there is not enough submarine capacity into the Australasian region so has to be coordinated overseas in at high capacity near global internet exchange points.

yitz: Historical DNS PTR records show ulco.telstraglobal.net for that 202.40.148.50 hop for which "ulco" is some PoP in the UK I believe.Not sure what's happened to telstraglobal.net DNS, seems they have rate limited it so intermittent resolution/caching.

The interesting thing is that 202.40.148.50 is ~130ms from San Jose and ~270ms from London (using an observation point that I have in each location, which are on networks that peer with AS4637 in each location).

The problem with their DNS is that the delegation for 148.40.202.in-addr.arpa points to ns03.net.reach.com which no longer exists. ns03.telstraglobal.net will answer if you give it direct queries. host$ dig +short @ns03.telstraglobal.net 49.148.40.202.in-addr.arpa ptri-0-4-0-13.ulco-core02.bi.telstraglobal.net.host$ dig +short @ns03.telstraglobal.net 50.148.40.202.in-addr.arpa ptri-1-0-0.ams01-grx.bi.telstraglobal.net. However, DNS isn't particularly trustworthy since linknets get reused all the time without DNS being updated. It's at best, a hint.

vitz: The return route is fine (you can probably check at lg.wargaming.net), so RTT is effectively a round trip to UK since UK goes via San Jose for most anyway.

Without knowing the source address it is challenging to validate the exact return, but picking a return from wargaming.net's Silicon Valley location to 203.98.50.2 does not go via London, although it confirms there is a problem (latency as it hits AS4637 jumps to 137ms).

I suppose from a latency perspective it is actually possible to be tromboning via London, from where I sit in Sunnyvale right now, some of those routers are latency close to me (i.e. not in the UK, or Hong Kong), but others are not. If it is going via London, then 300ms is actually pretty impressive for end-user latency given the one-way trip times required for each segment.

Edit: Actually, I'll concede it is going via the UK. But it's not traversing Hong Kong. As for "which moron decides", normally it's a routing protocol on a router. It's not like a person sits there and individually makes routing decisions.

yitz: If you lookup 192.184.12.13 and 208.64.123.97 they are the IPs for a DDoS mitigation provider, maybe the Vodafone UFB network has been considered amongst sources of the DDoS?

DDoS mitigation and filtering will always mean a crappy route as there is not enough submarine capacity into the Australasian region so has to be coordinated overseas in at high capacity near global internet exchange points.

I don't know where you found that information. In any case, the worst hop by far is between the addresses I highlighted, which is 124ms.

yitz: Historical DNS PTR records show ulco.telstraglobal.net for that 202.40.148.50 hop for which "ulco" is some PoP in the UK I believe.Not sure what's happened to telstraglobal.net DNS, seems they have rate limited it so intermittent resolution/caching.

The interesting thing is that 202.40.148.50 is ~130ms from San Jose and ~270ms from London (using an observation point that I have in each location, which are on networks that peer with AS4637 in each location).

The problem with their DNS is that the delegation for 148.40.202.in-addr.arpa points to ns03.net.reach.com which no longer exists. ns03.telstraglobal.net will answer if you give it direct queries. host$ dig +short @ns03.telstraglobal.net 49.148.40.202.in-addr.arpa ptri-0-4-0-13.ulco-core02.bi.telstraglobal.net.host$ dig +short @ns03.telstraglobal.net 50.148.40.202.in-addr.arpa ptri-1-0-0.ams01-grx.bi.telstraglobal.net. However, DNS isn't particularly trustworthy since linknets get reused all the time without DNS being updated. It's at best, a hint.

vitz: The return route is fine (you can probably check at lg.wargaming.net), so RTT is effectively a round trip to UK since UK goes via San Jose for most anyway.

Without knowing the source address it is challenging to validate the exact return, but picking a return from wargaming.net's Silicon Valley location to 203.98.50.2 does not go via London, although it confirms there is a problem (latency as it hits AS4637 jumps to 137ms).

I suppose from a latency perspective it is actually possible to be tromboning via London, from where I sit in Sunnyvale right now, some of those routers are latency close to me (i.e. not in the UK, or Hong Kong), but others are not. If it is going via London, then 300ms is actually pretty impressive for end-user latency given the one-way trip times required for each segment.

Edit: Actually, I'll concede it is going via the UK. But it's not traversing Hong Kong. As for "which moron decides", normally it's a routing protocol on a router. It's not like a person sits there and individually makes routing decisions.

By routing protocol do you mean routing table? If so, some individual set it that way, didn't they?

No. A routing protocol (such as OSPF, IS-IS and BGP) contributes to the routing table (RIB). Humans may configure the protocol (and associated policies such as metrics, cost, etc), but the protocols themselves exchange routes and determine the best paths. A final RIB is calculated and then pushed to the FIB.

There are >580K routes that make up the Internet DFZ. No human would ever make anything other than macro decisions on it - the protocols do the rest.

Occasionally, things happen that can cause sub-optimal decisions to be made. None of the protocols I mention use latency as an input, so they're making the best decision they can given the decision criteria they use.

PenultimateHop: No. A routing protocol (such as OSPF, IS-IS and BGP) contributes to the routing table (RIB). Humans may configure the protocol (and associated policies such as metrics, cost, etc), but the protocols themselves exchange routes and determine the best paths. A final RIB is calculated and then pushed to the FIB.

There are >580K routes that make up the Internet DFZ. No human would ever make anything other than macro decisions on it - the protocols do the rest.

Occasionally, things happen that can cause sub-optimal decisions to be made. None of the protocols I mention use latency as an input, so they're making the best decision they can given the decision criteria they use.

Why would a routing protocol not take latency into consideration when deciding the most optimal route?