Tunnelling

[Steve]

Some tunneling services do rent specific physical cable out, keep the bandwidth lower than normal and change the QoS. You are effectively being charged extra for traveling over a less congested line with different rules. Some just tunnel through SSH (repackaging) and thus get different rules for buffering applied to them as a consequence.

Obviously that's not going to be the case with the ocean cable, but it can be true of some of the cable in between.

[Sabindeus]

We're on the same ISP in Australia, and that ISP has trans-pacific capacity on 2 cables, both leaving from Sydney. One to San Jose, and one to LA. My traffic to Blizz and Smoothping, both in LA, goes via San Jose, so I'm assuming this cable is the "preferred" one. There's no sensible reason for Lev's packets from Queensland to take a different route to Sydney based on a small difference in destination. Internode's routing tables are just going to say "Packet for North America - route to PPC-1 cable".

No sensible reason. Doesn't mean it isn't happening!

You're right that once the packet lands in California the paths can diverge, and they do, due to the different transits and peering arrangements Internode have in their Exquinix San Jose PoP. I get a couple less hops and about 18ms better ping to Smoothping's endpoint than to Saurfang-US -- a difference of less than 10% of my ping, and less than 5% of Exo's.

If the tunnel service has an endpoint in Australia, there could be a big routing difference. They could use a Pacific crossing that might be less-congested (e.g. going via Telstra's Endeavour cable). I don't know if there are any such providers.

Physical round-trip-time Syd-Townsville is around 70ms. Lev has crappy Telstra ADSL, so add a few more ms. That his ping blows out to unplayable levels, and that a tunnel service improves it substantially, means there's something mis-configured somewhere.

I would place my bets on preferential treatment in the BGP or just local routing setup. Likely a more preferential route is being chosen because the packet is being labelled as originating from the tunnel endpoint in CA vs your home ISP in AU. (So not mis-configured per se, just not good for you and instead good for the ISPs involved.) I would love to inspect a traceroute from one of these tunnel services to Blizz's servers as compared to from your AU ISP, but that's probably impossible if they're setting up an SSH tunnel from their boxen to your box.

[rodos]

I would love to inspect a traceroute from one of these tunnel services to Blizz's servers as compared to from your AU ISP, but that's probably impossible if they're setting up an SSH tunnel from their boxen to your box.

I'm getting very tempted to run an Amazon EC2 instance for a couple of hours and do not just some path tracing but also some packet dumping while running WoW through an SSH tunnel, to see if I can see anything funny in the way the WoW servers respond. I still think some kind of Nagle or delayed-ack problem is pretty likely.

This looks like a promising way to twiddle with the latency for testing purposes too:
http://people.redhat.com/berrange/notes/network-delay.html

Of course, doing any of this could get me banned for hacking on the network traffic.