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)
This also make sense in terms of fighting latency as well since it allows efficient traffic over IPv6 on high bandwidth links (ISP to ISP) and last mile content proxy mechnism for optional clients (Win XP can do IPv6 from SP1).. VOIP will do the same with SIP termination points as the application proxy.
Some of my sites are hosted in Kansas City,MO which is a common location for many large data centers in the US, Kansas is a popular place for building data centers because it provides equal network latency for both east and west cost clients due to its central location (latency depends on the length of the actual link, i.e. how long is the transmitting optical fiber cable).
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.
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).
During the last four years I have been using JavaScript frameworks across many of the sites I have been developing, I found the Mootools syntax and object oriented approach to be the most intuitive to code with and JQuery to be the easiest to integrate with additional existing JavaScript libraries (with its excellent NoConflict mode).
When it comes to creating front-end functionality for integrating with ASP.NET, JQuery is definitively the framework of choice with its full Visual Studio integration and recent Microsoft’s support.
One of the main drives for utilising JQuery will be latency optimisation, where the entire load for functionality and client side validation could be offloaded for CDN delivery, reducing network delivery overhead.
This approach could be demonstrated with a recent implementation I have been involved with (see below) :
where a heavily requested travel sites is optimised for a quick initial load time with extensive client side validation, reducing server load and minimizing network communication (and its potential latency overhead).
Had a bit of experimenting on multihoming using BGP, the main idea is using BGP4 to announce an address space to all upstream links out side the autonomous system (AS) . This is particularly good for scenarios where a routing path requires high availability (allowing swapping of a cluster while serving web requests from different data centres with no down time), but is also experimented for load balancing global resources (serving the same web content from different locations).
I have got into BGP4 from my work on GeoWeb apps a few years ago when I realised that with BGP4 and dynamically created routing tables you cannot rely on IP address alone for identifying a requesting connection’s physical location (see here).
The bottom line is that when coming to implement a fast loading rich mapping solution(or any other mash-up), it is significantly important to know the client’s physical location (for serving content from closer locations) and knowing its IP is not enough any more!!
possible scenario from a New Zealand Australia optimisation case(implemented within a Melbourne mash-up)
Kansas City 1869
