the New Zealand Internet Industry will get a major boost in its potential growth.

The existing Southern Cross cable architecture introduces a significant latency factor due to the commercial decision to terminate all legs at Maui (Hawaii).

This doesn’t have a major effect on data speed and bandwidth (with powerful routers in Hawaii) although introduces major challenges for VoIP communication where the call quality is determined by latency (number of hops and carrier distance).

With a direct link from California to Auckland and a straight cross over the Tasman either to Sydney or Melbourne (see below):

(source: http://www.pacificfibre.net)

and  the rapid growth in VoIP usage across the pacific, Australian VoIP providers and voice operators such as CRM and call centres will find NZ  a very attractive environment, located close enough to Australia and right on one of the Pacific’s best communication hubs.

We are currently experimenting in SIP packets routing thorough Asia(Singapore) and US (Virginia) for optimizing global voice link to Europe. stats soon.

Thanks to Vladimir Verlinsky for the TCP/IP BGP4 routing leads.

click here for Australian / New Zealand Versions.

and starting to really like SharePoint 2007 (SP2 onwards), excellent .NET application container that allows you to define your cache policies and expiry periods(BLOB, Output and Object Caching) and fine tune expiry periods.

a Nice feature is when you really need to go spatial (GIS queries and mapping UI) you can use native SQL Server as your data store and still have content and media resources caching managed by IIS/Load-balancer.

When dealing with Australian and New Zealand mash-ups I believe the best way is maintaining a data store with well defined expiry periods (e.g. traffic vs. weather vs. external providers cached content) and later distributing its static elements into the cloud.

I have been experimenting with Amazons EC2 services for a real estate related research project (heat mapping commercial property stats) and Amazon has excellent .NET hooks allowing you to push content out to the cloud and later reference it within .net applications (or any other content blocks), this methods significantly reduce bandwidth costs/server maintenance overhead and improves response and serving time by reducing latency.

The architecture illustrated below will provide a SharePoint managed CDN for $0.15 USD per GB of traffic (based on Amazon’s current data transfer price plan):

This page has been constructed out of content distributed from three different continents, so the bottom line is:

“use out of the box content management tools and distribute its product using cloud services”.

my Coromandel mates told me this summer its up on the agenda again (see: Coromandel WatchDog).

We lived in the Coromandel for over two years and had great two weeks in this beautiful green bush on Xmas,  will be back as every summer next year!!

a cool Coromandel itinerary I have recommended for several of my overseas mates could be seen here.

This is introduce a major challenge while developing and hosting NZ/AU based web application, which many believe could be addressed using the following delivery techniques:

1) Identify your main landing pages for your primary key terms and define the most frequently managed content (banners, specials, news etc.) and push the container HTML out to the cloud managing the content using iframes or content deployment technologies (such as SharePoint).

2) Using more frequently updated pages with heavier functionality as link juice back into those primary fast loading landings pages.

3) Its been confirmed that both Bing and Google will not penalize on repeating content within sub domains (e.g. nz.mysite.com and au.mysite.com) allowing regional content and location related functionality to exist closer to its potential audience while containing similar data and templates.

4) Following the Latency Recommendations for AU/NZ based web pages for minimising the response time only to the one introduced as a result of router hops and distance.

2010 will be a good year for optimising South Pacific content, ensuring high ranking on future mobile device based search results(these will have only five relevant winners on the first page ;o)

web mapping capabilities and internet UI (animation and front-end stuff) still has lots of potential giving the fact that the local script (Hangul) is all left to right with a nice reasonable 24 character set.. and could run Joomla almost out of the box!!

I have done a few speed/load tests from downtown Seoul, lots of router hops on a really good link, latency to NZ/AU was pretty big though..

I have stated looking into deploying Win2008 which made me do a bit of research on Ipv6 tunneling and coexisting it with IPv4.

Voice over IP can survive low bandwidth but has hard time with network latency (a human syllable averages 200ms-300ms) so choosing the best possible IP implementation will effect the transmitted voice quality), this makes AU/NZ VOIP a real interesting challenge.

These seem to be the main network/transport level solution I came across:

ISATAP: uses Dual-stack nodes to automatically tunnel IPv6 packets in IPv4, i.e., ISATAP views the IPv4 network as a link layer for Ipv6.

Teredo: creates IPv6 connectivity by tunneling packets over UDP, Teredo service runs by sing “Teredo servers” and “Teredo relays”.  Teredo relays act as IPv6 routers between the Teredo service and the native” IPv6 Internet.

6to4: treats the NAT box as a point to point link layer router into the native Ipv4 network and abstracts the global routing by using the NAT gateway as its Ipv6 termination point.

Tunnel Brokers: uses dedicated servers, called Brokers, to automatically manage tunnel requests coming from the Ipv6 client. Maps isolated IPv6 clients to agree on the routing tables used, allows the client to connect and activate IPv6 connections to other IPv6 by creating a virtual network between the Ipv6/IPv6 dual stack nodes. Dual stack users are nodes that can implement both protocols and uses the v4 implementation for the encapsulation mechanism.

From knowing how Cisco and Junipers are working together my guess will be that dual stack application level proxies (HTTP, SIP) that allows serving clients on both protocols will be the most common implementation in the short term (i.e. ISPs will be able to negotiate optional delivery methods over the available link and allow all types of client to receive the relevant service according to the clients protocol capabilities(blue coat seems to have a lot of research going in this direction)

Kansas City was initially built because of the strategic confluence of the Kansas and Missouri rivers that provided good steam ship transport through the Mississippi-Missouri river.

Kansas City 1869

Being a large population center on the river it had one of the first major railroad bridges across the Missouri  which made the city a major south to north east to west railroads hub

Once the optical fiber network infrastructure used by the core of today’s Internet was build, the public land of the railroad grid has been utilised for laying out the cables making it the new communication highway, Kansas once again became a major network/data center hub (all of this because the same bridge on the same old river..)

(source: colocationmontreal.com).

I am currently running most of my response time and web latency tests from Dallas and Kansas which provides extremely reliable results giving the infrastructure and location of those data centers.

http://ajaxian.com/archives/gmail-mobile-latency

This one speeds the loading of a mobile web page + full parsing of  the interaction layer(Javascript) from 2600ms to 240ms (10 faster!!) on the same script block size(200KB)!!

Worth trying when customising web apps for moblies (which has good 3G bandwidth but really bad  latency due to the transport over microwave).