Google 'local peering' live?

From some traceroute data [target: www.blogger.com]:

9 unknown.uni.net.za (155.232.253.254) 2.341 ms 2.055 ms 2.237 ms
10 64.233.174.40 151.205 ms 151.276 ms 151.457 ms

Note the jump in RTT as we go from the TENET router to the Google router (64.233.160.0/19 belongs to Google).

Compare to traceroute data for a less aggressively-peering company [target: www.microsoft.com]:

8 v2750-tiger-brie.uni.net.za (155.232.145.226) 2.341 ms 2.254 ms 2.337 ms

9 unknown.uni.net.za (196.32.209.25) 153.050 ms 152.938 ms 152.223 ms

Where the next hop is a TENET-controlled router overseas.

So perhaps Google has started 'peering locally', and are transparently tunneling the data overseas to allow IS [and/or other ISPs] to avoid paying for each user's international bandwidth. Of course Google are therefore paying for it, but with the standard international bandwidth pricing feedback damping the usage, they probably aren't seeing a huge explosion in bandwidth demand.

Contrast this to the local YouTube traffic caching, where having locally-available video means that videos load faster: better user experience translates to higher usage, and the demand increases. For the user this is a virtuous circle, but to the various I[C]T[S] departments it must seem more like a vicious circle.

However, for organisations like TENET where the pipe is purchased old-school (i.e. 'per Mbps' rather than 'per GB'), this will be a boon, because up to 40 Mbps [peak] is now being handed-off locally. Interestingly the upstream/outbound traffic, presumably web crawling, is still going through the Ubuntunet point in London.

Some graphs:

The London peering session going [relatively] quiet late Tuesday.

A 'local peering' session [presumably with Google] in Cape Town going live late Tuesday:

And some of the local caching traffic seems strongly correlated (via Mk. 1 eyeball-based peak matching on other graphs) to the local peering session.

The takeaway: Google is probably peering locally, but is trying to avoid flooding ISPs with bandwidth-conversion economic problems.

iPhone + Geolocation + P2P

Since Apple's announced new embeddable Google Maps for the iPhone, not to mention the new P2P support, perhaps it's not too much to ask to get a cool new proximity-based alerting system?

Such a system could be used for geocaching or even friend-finding (the real kind of friend-finding where you already know the person...)

TENET has new transit providers

The TENET traffic graphs show NTT as a new provider:

And a 10G interface, to boot! This is likely in preparation for the arrival of SEACOM, as TENET's international bandwidth is the current bottleneck.

Traffic on Datahop has been halved, and traffic on Telias is at a quarter to a third of normal rates. So they are either being phased out or being used as backup providers.

UCT permanent upgrade to 43 Mbps

The bandwidth test was obviously successful as UCT has upgraded their connection to 43 Mbps. Graphs at the usual place [notice the jump around 12.30pm].

ICTS has issued a remarkably restrained notice. Did they not trumpet this to the whole campus because:

• it's a drop in the bucket compared to the demand?
• they don't want to stimulate further demand?
• they don't want any recognition?

Whatever the reason, we still look forward to the upcoming 1 Gbps temporary link for TSN 63 (UCT)

Google resolving locally

When resolving www.google.co.za from within TENET IP space, one now receives A records indicating TENET IP addresses.

There are still some holdouts - kh.google.com / mwx.google.com and mail.google.com still resolve to normal Google IP addresses. Perhaps they'll transition soon.