Книга: Code 2.0
As I said, we can distinguish cyberspace from the Internet. But the point of this chapter, however clear with respect to cyberspace, is still true of the Internet. There are architectural features of the Internet that embed certain values. Those features can also change, and if they do, the values the Internet promotes will be different.
The most significant example of this is one I only mentioned in the first edition of this book, but which was at the center of The Future of Ideas. This is the “end-to-end” principle described by network architects Jerome Saltzer, David Clark, and David Reed in 1981. The end-to-end (“e2e”) principle is a design philosophy about how networks should be built. It counsels that a network should be kept as simple as possible and that the intelligence required in a network be vested in the edge, or ends of a network, at least so far as that’s possible.
As I’ve already described, the Internet embodied this principle by keeping the functionality of TCP/IP focused quite narrowly — that is, on the single function best-efforts delivery of packets of data. What those packets do, or who they’re meant for, is not a concern of the protocol. Just delivering packets is the end.
One consequence of this design, then, is that people can innovate for this network without any need to coordinate with any network owner. If you want to develop an application to deliver voice across IP, then all you need to do is to write the application to use the TCP/IP protocols to send data across the network in a way that will make your application run.
This design embeds a value that encourages innovation in applications for the network. It does so both because it minimizes the costs of developing new applications (you don’t need the hassle of asking or clearing permission with anyone) and because it avoids strategic behavior by the network owner. Consider again the idea of developing a Voice-over-IP application. If the network is owned by the telephone companies, they would not be excited about an application that will cannibalize their telephone market. Thus, if permission were required before the VOIP application could be deployed, we might well expect the VOIP application not to be deployed — either because someone developed it, but it was blocked, or because smart developers knew it was a waste of time to develop it, because it would be blocked. As Susan Crawford describes, “The miraculous growth of the Internet has in large part come from the nondiscrimination against higher levels. . . . Innovators at the application layer have been able to assume the continued stable existence of the lower layers.”
The value here is innovation and competition. The network empowers the widest range of innovators — users of the network — and entitles all of them to innovate for this network. Any innovation can be deployed on the network (so long as it respects the TCP/IP protocols). If users of the network like the innovation, then the innovation is a success.
Simultaneously — at least so long as the e2e principle is respected — this design disables the potentially most powerful actor in the network, the network owner, from interfering with the opportunity for innovation within the network. The network owner might not like the stuff being developed, but e2e disables the opportunity to block that development.
In the same way that the original TCP/IP network could be effectively changed so that “gaps” in information about that network could be closed, the TCP/IP network could be changed to remove its e2e character. Indeed, the very tools that I described in Chapter 4 could have this effect. For example, a network owner could scan the packets that were traveling across its network and block any packet that didn’t come from a known, or approved, application. To get on that list, application developers would have to contact the network owner and ask to be included on the list. That change to the way the Internet functions is completely technically possible. Indeed, versions of it are being pursued for both competitive and security reasons. That is, some networks, keen to control the kind of applications that run on the network for competitive reasons, could use this to block disfavored applications (again, think of telephone companies blocking VOIP). Others, keen to avoid viruses or other trouble on their network, could simply decide to block everything to make life simple. Either reason would produce the same result: that innovation on the Internet would be stifled.
As with the stories about “cyberspace”, this case about the Internet also demonstrates the link between architecture and policy. End-to-end is a paradigm for technology that embeds values. Which architecture we encourage is a choice about which policy we encourage. This is true even in the context in which the Internet is not a “place” — even where, that is, it is “just” a medium.
- 4.4.4 The Dispatcher
- About the author
- Appendix E. Other resources and links
- Example NAT machine in theory
- The final stage of our NAT machine
- CHAPTER 5 On the Internet
- Browsing the Internet
- Beyond the Network and Onto the Internet
- Using the Fedora Internet Configuration Wizard
- Thread resources on the Internet
- 7.5.3. The Fast Local Internet Protocol
- The Internet Control Message Protocol