open-cgf release 0.1

Well open-cgf doesn't get much attention, which is not that surprising given it's limited market appeal - you really have to own an SGSN or GGSN.

For those that are interested I have created a release tarball v0.1, which you can download from here.

Comments welcome. I need users who can run it against their hardware and report faults (and/or success!).

Hosting close to your customers

In pre-industrial times, flour mills were placed close to the points of wheat production and consumption. It was hard and expensive to transport the wheat and resulting flour too far. The technology was hard, but not impossible, to replicate.

In industrial revolution times, factories were placed close to the point of raw material sourcing, canning factories beside farms, since transportation wasn't fast enough to transport the material before it went bad. However once processed it could be sent to warehouses anywhere, using economic shipping methods, for later distribution.

Skipping forward, now we're in Web 2.0 land. Our customers are everywhere, but really we will have geographical hotspots. At least if I split the world into broad geographical areas you'll probably have North American, Asia, and European customers (these being the general areas of Internet user concentration presently).

Connectivity

See this map?


See all those cables in the Northern Hemisphere? Abundant connectivity, short direct routes.

So why would you host content that required traffic to route all the way to, for example, New Zealand? Isn't this the equivalent of shipping logs to Japan for processing into paper, something that is possible but inefficient? Akamai know this, and have provided simple content hosting for yonks.

Fast international connectivity is useful to provide access for a broad base of consumers and to provide content providers a way to distribute their content. However I posit that distributing the content means to get it from the point of production to servers close to the point of consumption. It does not mean you need to host it in the content producer's back yard.

If I had content application with a worldwide focus, then I'd host my test and pre-deployment servers next to my company; but the production servers would be designed to be geographically distributed and my first one would be in the USA. The reason is that the USA gets free international bandwidth (pdf) and this flows into hosting deals you simply can't say no to. 2TB a month for US$29 in my case.

Once the US base, with cheap reliable hosting, was covered I would then target the geographical hotspots. The reason for doing this is not cost since the cost is likely to be higher, but latency.

Latency

Latency hurts Web 2.0 content. We have moved beyond simple pages with a few graphics. Applications now have many many server to client roundtrips, a lot of them sequential.

With a simple page loading some images that allows a browser to use multiple parallel connections and pipelining will get content served very quickly.

A SaaS application that uses multiple XML request/responses, for example a search-as-you-type application, can not use any of these. Latency becomes very noticable.

A local example, from my home computer, gives about ~2oms latency to local content. US content is ~200ms. Ten times slower. Human perception of delays starts kicking in at under 400ms (cf. telephony G.114 standard), and at 200ms per roundtrip without any server processing delay that will be exceeded very quickly.

The result is that a locally hosted SaaS application will "pop" onto your screen and should seem as responsive as a thick client. A distantly hosted application will have noticable (and inconsistent: jitter) delays. Your customers will notice this and regard your product as inferior.

Faster Pipes and Servers Don't Matter
Laying more fibre to your centralised data centre will not solve the latency issue. There are some limited benefits you can obtain by organising more direct peering into other hot spots, but there are things as fundamental as the speed of electrons/light working against it. You can't control the rest of the internet routing.

Faster servers can reduce the latency due to processing the request, but these delays are independent of the geographic location of the user and therefore should already be addressed by local performance testing.

What is next?

PaaS providers, like Google, will probably do geographic hosting automatically for you. I've not had a chance to look closer at App Engine yet, but it is rumoured to auto-spread the load through the cloud. Auto-spreading across geography is the next logical step.

Emails from the closet

I was pretty amazed, and then horrified, by the recent recovery of an Infocomm shared drive backup.

Very interesting reading, especially if you played any of the Infocoom games (Zork, HHGTTG etc). However I know I wouldn't want my corporate emails dug up and displayed nearly 20 years after the event. This is not because they are machiavellian and/or nasty, but just because what I said in private to one person 20 years ago was meant to stay, well, private and 20 years ago.

The original author's have turned up in the comments and are unimpressed.

This sort of stuff is far more dangerous than newsgroup ranting/posting, embarrassing facebook photos, or weird blog postings from your emo/goth/etc phase. That stuff you intended to be public, even if you didn't intend it to be public, backed up, and then displayed as a corporate screensaver 20 years later.

PS No, not that closet. The orange one on the left.
Edit: "not" added. FFS.