The Great Carrier MPLS Rip-Off

www.cmpnet.com
The Technology Network

The Great Carrier MPLS Rip-Off
By Jack Sadot 03/01/2006 12:00 AM ESTURL: http://www.itarchitect.com/shared/article/showArticle.jhtml?articleId=180201636

Back in the late 1990s, private networks made sense for connecting overseas offices. The Internet wasn't considered enterprise-class, and frame relay lines with a 25 percent Committed Information Rate (CIR) were sufficient for most offices. Times have changed. Today Multiprotocol Label Switching (MPLS) is "in" and frame relay "out." However, IT architects should still avoid private networking technologies and use Internet VPNs to interconnect offices--even remote offices running VoIP.

This fact hit home for me about a year ago when we began major offshore development in India. I wasn't ready to take risks at the time, so I fought to get the best possible deal on private lines for the development site, finally settling on a global provider with excellent references in India that offered us a private network with impressive SLAs for both availability and latency. My justification for ordering lines costing five times more than a local Internet connection was that we didn't know what we'd encounter, this being our first real attempt at decentralizing our development teams.

The vendor kept its word with all that was under its control. Performance met the SLA, but not availability. Unfortunately, the SLA didn't cover outages due to local loop problems, and in India there are plenty of those. India's substandard infrastructure is easily affected by construction, weather, and haphazard procedures.

Compared to our smaller Indian non-development office running an ADSL line, the only real differences were the attentive support and high price. Performance was amazingly similar between the two sites. The SLA called for 275ms door-to-door, and with the VPN overhead we measured 295ms. The ADSL-based VPN measured 305ms.

Even VoIP quality was fine over the ADSL link. As long as we give priority to a limited and specific set of services, such as VoIP and interactive data, and as long as we avoid complex rules that attempt to avoid prioritizing down to the specific application, we're able to accomplish what we need with an Internet connection. Our VoIP network, based on AudioCodes gateways attached to standard PBXs, requires just 18Kbps per session for voice, so we can plan for several of those even on an ADSL line with a 192Kbps upload speed.

While we do suffer performance problems throughout the Asia-Pacific region, particularly in difficult-to-connect countries such as India and Indonesia, these cases are usually due to limitations of the speed of light or poor local infrastructure, both of which also afflict frame relay and even MPLS networks. Our experience throughout the world is that Internet connections are stable and have surprisingly low jitter. VoIP connection works well, and where we decide to use a separate infrastructure for voice and data, we do so using additional ADSL lines.

Sticking with an ISP also means we control the vendor relationship. A month doesn't go by when we don't add or change a line somewhere. Where we see chronic problems not typical of the local infrastructure, we simply switch ISPs. Because we're not locked into any global agreements, we're consistently able to increase bandwidth while containing or cutting costs.

With the results of our initial VPN connections over the Internet so encouraging, we've expanded their use around the globe. As we work with local vendors to achieve the best terms in each location, we see all sorts of business models and levels of service. In the final analysis, however, we've found that Internet-based connections always win out over private networks. The connectivity that the Internet offers may not be perfect, but it's good enough, and for us architects on a tight budget that's exactly what we're after.

Jack Sadot is an IT architect at an S&P 500 company with 5,000 employees, several hundred subcontracts, and offices in over 50 locations worldwide.



www.cmpnet.com
The Technology Network
Copyright 2002 © CMP Media, LLC