Issue No.02 - March-April (2013 vol.17)
Published by the IEEE Computer Society
Vinton G. Cerf , Google
DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/MIC.2013.34
Rigid designs are often brittle under stress; loosely coupled systems, on the other hand, can withstand changing conditions and stresses more effectively. Such designs are often more adaptable. Currency exchange rates, information hiding, and the design of earthquake-resistant buildings all share this loose coupling property.
I have been thinking recently about resilience and design, and have come to believe that there might be a principle of sorts in the term "loose coupling" that could inform the design of highly resilient systems. A few examples come to mind. In the case of the Internet, there are actually several.
One of the features of the Internet Protocol (IP) that Bob Kahn and I strongly favored was insensitivity to the nature of the underlying transmission (carriage) of Internet packets. (To be precise, we adopted this view in our design of the original Transmission Control Protocol [TCP] that was later split into IP and a newly renamed TCP that was responsible only for end-to-end flow control, error/loss correction, and multiplexing.) We knew in 1973 that new communication technologies would be developed over the years and decades ahead, and we wanted the Internet's design to be able to incorporate any of them into its architecture. This form of loose coupling has let the Internet use a rich variety of underlying transmission mechanisms without making any changes to IP itself. The "coupling" mechanism occurs through a convergence layer that embeds IP packets into the underlying link-layer frames.
Another example is the way in which distinct networks (sometimes called "autonomous systems" in Internet parlance) interact with one another. The Border Gateway Protocol (BGP) is used to exchange connectivity information and some "preference" information that affects routing choices. Apart from the limited information this internetwork routing mechanism exchanges between networks, the networks themselves are sovereign within their own borders, so to speak. They choose their own hardware and software, make interconnection decisions independently through mutual negotiations, and invest in infrastructure independently. They operate independently but cooperatively.
A third example arises from the IETF ( www.ietf.org), which operates under the auspices of the Internet Society (ISOC; www.isoc.org). It isn't possible to become a "member" of the IETF because there is no place to sign up, and the organization is an unincorporated entity. However, anyone who wishes can simply show up and participate. Some participants have never actually come to a physical face-to-face meeting because all proceedings eventually wind up with a "last call" on the Internet that can be answered through email on working group distribution lists. Many contributions and discussions enter into the system by these online means. I consider this to be a form of loose organizational coupling.
We might say the same for the different institutions that have grown up around the Internet. ICANN ( www.icann.org) is an example. Its multi-stakeholder structure has numerous supporting organizations through which policy is developed. Included in the structure are the technical community, civil society, the private sector, and national governments. It's probably fair to say that the ICANN structure is somewhat tighter than the other examples given, but there's a lot of latitude in how the various supporting organizations interact with each other. The interactions among ICANN, ISOC, the IETF, the root servers, the Regional Internet Registries (RIRs; see www.arin.net, www.apnic.net, www.lacnic.net, www.afrinic.net, www.ripe.net, and www.nro.net), and the US National Telecommunications and Information Administration (NTIA; www.ntia.doc.gov) represent another good example of loose coupling.
The point about all of these examples is that they allow for a degree of latitude and flexibility in operation, in some cases both internally and externally. Latitude (and even ambiguity) can sometimes be helpful in creating a successful collaborative environment. Although it's often the case that highly efficient and powerful systems (think "supercomputer") rely on very tight design specifications for their effectiveness, they can also be quite brittle when all parameters aren't exactly tuned to perfection. Loosely coupled systems, however, can tolerate a great deal of stress and political "sturm und drang." They can adapt to changing circumstances without requiring, for example, the moral equivalent of a Constitutional Convention.
Mechanical and civil engineers understand this principle and incorporate it into their designs. Universal joints are often designed to be somewhat loosely coupled to cope with rough road surfaces. In earthquake-prone areas, buildings are deliberately designed to sway with the motion of the Earth and not break suddenly, whereas a rigid design might fail if the stress exceeds some limit. We can think of a tree as a loosely coupled system as it bends and sways even in hurricane-force winds.
We can find another example in the currency exchange system that allows for floating exchange rates to adapt different economies and their currencies to the vicissitudes of the financial markets. Arguably, the situation in the Eurozone is more difficult precisely because Europe's widely varying economies are tightly linked by a common currency. The flexibility of exchange rates is lost in this linkage.
The point of this essay is simply to draw attention to loose coupling's value as a design choice when systems are likely to encounter physical, financial, technical, or political stresses that would break a more rigid design. Sometimes, there's a price to pay for this choice, as loosely coupled systems might be less efficient than their more rigid and finely tuned counterparts. Resilience might be its own reward, however, for many practical situations.
Vinton G. Cerf is vice president and chief Internet evangelist at Google, and president of ACM. Contact him at firstname.lastname@example.org.