Simple Caveman IP Engineer

In the late 1980s, Saturday Night Live had a running sketch with Phil Hartman as The Unfrozen Caveman Lawyer. The joke was that the caveman claimed that his primitive mind could not grasp the complexities of modern life, yet he proved skillful in winning over juries using simple wisdom. I think about this sketch when I read about complexity in network design.

In my work, I am a proponent of simplicity in IP networks. Having spent a good part of my 14 year career in Operations environments, I know how simplicity enables an Ops organization to quickly resolve problems in a manner that scales as the network grows.

Do you think you could explain your network architecture to an IP savvy engineer within an hour’s time? If not, how will the NOC fix the network when it fails at 3 am? Perhaps you have a bevy of PhDs willing to perform on-call duties.

But hey…what do I know? I’m just a simple caveman IP engineer.


Google’s Approach to Network Design

Light Reading’s  Craig Matsumoto posted an interesting article about Google’s effort to influence its suppliers to loosen optical component requirements.

Here is the key paragraph.

Vijay Vusirikala, an optical architect with Google, explained that Google thinks it can save money and speed optical module development times by eliminating some of the corner cases that telecom gear is required to meet — loosening the requirements, in other words. A Google data center never gets to 0 degrees Celsius, for instance — so why does it need components built to withstand that temperature?

Telcos view IP networks through a lens of the POTS network provider. Considering every corner case possible helped achieve impressive reliability. The fail-over characteristics of an IP network change the requirements. I applaud Google for using approach that is dissimilar to that of a telco.  Two aspects come to mind.

  1. Google has built an IP infrastructure to suit the needs of a modern IP network.  The bit error rate of 10-15 was a requirement for TDM networks. The end points in an IP network can tolerate packet loss. The marginal benefit of a 10-15 BER transceiver over a 10-12 BER one does not warrant the additional cost and development time. Don’t over-invest in components that meet outdated requirements.
  1. Google envisions its solution set to include more than what is commercially available. The Google backbone engineers ask, “What is needed to deliver an IP service at the least possible cost?” Google encourages its vendors to build products its designers deem necessary. Compare this to the telco approach of relying heavily on vendors to design and implement a network. The resulting network typically exhibits unnecessary complexity and proprietary elements.

For more insight into Google’s design philosophy, check out Vijay Gill’s Worse is Better keynote address at NANOG 49.