Narrow Waists and Big Ideas
One of the things we try to do in all of our books is highlight the system design principles illustrated by specific technologies. In our main book, these are highlighted as Key Takeaways, and we’ve linked them together in the on-line version so it’s easy to follow the chain. Collectively, they define what we believe every student of the Internet should know. In a similar vein, we’ve linked together the Perspectives at the end of each chapter. They collectively describe the forces that we expect to shape the Internet into the future. This week’s post follows one particular storyline drawn from those two chains.
I find myself preparing for a guest lecture Muhammad Shahbaz invited me to give to his undergrad networking class at Purdue. It’s near the end of the semester, so the students have already learned everything they need to know about congestion control and routing algorithms, which frees me up to talk about “big picture” topics. This leaves me asking myself: “What insights should every student take away from a networking course, but might have missed in a can’t -see-the-forest-for-the-trees way?”
At the top of my list is an appreciation for the genius of an architecture that survived 40 years while launching a society-transforming technology. That architecture is typically described in terms of the Hourglass Design, with IP serving as the narrow waist. Recognizing the power of the Hourglass Design is an important “first-class” takeaway from any networking class because of its general applicability to any system that aspires to wide-spread adoption. But there’s value in looking at the lessons of the Internet a little more deeply, especially with respect to how the Internet of 40 years ago evolved into today’s cloud, as well as how it might continue to evolve in the future. Let me try to connect the dots between four big ideas.
The first is the narrowness of the narrow waist. When designing a system, it’s natural to try to address as many of the known technical requirements as possible, and in doing so, over-engineer the system. (This affliction is notoriously common when building a second-system.) The beauty of IP’s design is that it solved exactly one of the many problems it might have tried to address—defining a global addressing/routing scheme—and it punted on everything else, including reliable delivery, security, mobility, quality-of-service and so on. This left ample room for others to innovate, and claim a stake in the Internet’s future.
Internet pioneers have long ruminated about not addressing security in the original design, but doing so would likely have (a) not anticipated all the real-world threats, and (b) made wide-spread adoption more difficult. There have been many attempts through the years to establish “universal” networking technologies (ATM comes to mind), but the lesson is that if you have to achieve universal buy-in, agree to the minimal and least controversial thing necessary to get started. The design principle is inspired by the idea of late binding: Create a minimal-but-general framework today and postpone filling in use-case specific details for others to tackle tomorrow, when everyone better understands the requirements.
The second is having a reference implementation of the architecture that people can build upon. Such an open, minimum viable platform was initially defined by TCP/IP wrapped with the Socket API, and it catalyzed the first generation of client/server-based Internet services. This strong connection between architecture and implementation was part of the early Internet’s ethos, but even then, it was common to focus so narrowly on the over-the-wire protocol definition that it was easy to overlook the value of a platform that includes a well-defined API. It’s the API that spurs adoption. Fortunately, the generality of the Socket API was sufficient to get the ball rolling, which takes me to my next point.
The third big idea is to design for evolution. This is largely the consequence of starting with a narrow waist and backing it up with a running platform/interface. Evolution is enabled by building new abstractions on top of the existing platform, and in the process, incrementally completing the platform. We often take this for granted, but not all communication architectures are defined this way, with the mobile cellular network serving as a great counterexample. Each generation of the mobile network introduced new technologies, but unnecessarily (in our view) coupled the architecture with the technology. This ensured that every time the technology changed, the architecture had to change as well. (5G has the potential to end that cycle by embracing a cloud-based architecture, but it also leaves the door open to continuing legacy practices.)
In the case of the Internet, TCP obviously extended IP with support for reliable byte-streams, and including it as part of the reference platform (but not the narrow waist) was essential. And with the Socket API bootstrapping the TCP/IP platform, over time the platform then grew to address security (TLS), mobility (DHCP, HTTP redirects), and universal object identity (URIs), with HTTP’s RESTful interface capping off today’s ubiquitous platform. This platform has not only fueled a generation of cloud apps, but it has also made it possible to realize many of the features originally targeted at the Internet core (multicast is a great example) as cloud-hosted services.
Which brings me to my final point. Feature velocity—the speed at which platform evolution happens—is now as much an operational challenge as it is a feature development problem. My experience is that integrating and operationalizing new features often gates their deployment, but interestingly, the platform evolution we’ve been discussing has also (by necessity) led to more agile operational practices. By defining communication functionality in software running on commodity hardware (sometimes as services running on top of the cloud, sometimes as services running within the cloud substrate), a symbiotic relationship now exists: the Internet provides the communication platform for the cloud, and the cloud provides the lifecycle management platform for the Internet.
This tour of architectural ideas is prone to revisionism (and only hints at some of the other contributing factors), but connecting the dots from Cerf and Kahn’s 1974 TCP/IP paper to the state of today’s Internet/Cloud is remarkably direct and cogent: (1) start with a minimal architectural agreement; (2) translate that agreement into a minimum viable platform with a well-defined API that others can build upon; (3) evolve the system by incrementally layering platform upon platform; and then (4) leverage that global cloud you just built to operationalize the network and increase feature velocity into the future. And that’s the “systems approach” story I plan to share with the students.
In our previous newsletter we managed to be inconsistent with our capitalization of “Internet”. We corrected the post to be consistent with what we (and many other networking people) believe to be the appropriate style: capitalize Internet when referring to the global network; use lower case internet when referring to a generic internetwork. That puts us at odds with style guides from AP and Chicago but we like to think that’s because they don’t know that such things as generic internetworks exist. Just don’t get us started on “on premises”.