THE LAST WALTZ AND moving beyond TCP/iP John Nolan Is the TCP/IP protocol suite approaching its Last Waltz? John Architecture: A Return to Fundamentals within the IP Journal Nolan poses the question after examining the work of John [1]. Further research then led him to The Pouzin Society [2] Day, following a review of his book, Patterns in Network and in particular to the paper that follows on these pages1. Moving beyond TCP/IP1 Fred Goldstein and John Day for the Pouzin Society - June 2011. he triumph of the Trans- mission Control Proto- col/Internet Protocol (TCP/IP) protocol suite in today’s market is Tnearly complete. A monoculture of networking has emerged, based on protocols originally developed in the 1970s. With a near-universal use of IP for purposes well beyond the original designers’ intent, conven- tional wisdom holds that all future solutions must slowly evolve from it. This belief, however popular, is not necessarily correct. The Internet itself has been a popular success in large part because of its low-price business model. IP has absorbed the glow from the Internet’s halo. People confuse the Internet with its protocols. But they are not the same thing. TCP/IP has been a 30-year dis- traction from real internetworking. In a real sense, it is the networking equivalent of Microsoft DOS (Disk Operating System). For the Internet to prosper in the long term, it needs to move beyond TCP/IP. TCP/IP waS DESIGNED FOR A LIMITED SET OF taSKS TCP/IP was designed for the Ad- vanced Research Projects Agency Network (ARPANET), a Department of Defense resource-sharing network. When the ARPANET began in 1969, it demonstrated the then-radical no- tion of packet switching. The original ARPANET protocol, Network Control Program (NCP), was designed to en- sure reliability of transmission on a hop-by-hop basis. That ARPANET 42 | Volume 5 Part 3 • 2011 THE JOURNAL OF THE INSTITUTE OF TELECOMMUNICATIONS PROFESSIONALS is not today’s Internet. It was more the first connectionless network, connectionless middle. It was an “in- like the X.25 packet-switched net- CYCLADES, in 1972. But there was ternet” because it originally ran atop works that were developed later in much work still to do when political other networks, such as NCP and the 1970s. pressure shut down the project. X.25, allowing their respective users A French researcher, Louis Pouzin, ARPANET developers adopted the to share information. Certain ques- postulated that the switches in the connectionless idea, but failed to tions, like congestion control, still middle of the network didn’t have see the work that was still needed needed to be answered, but as key to keep track of connections; they to create a basic architecture They personnel changed in the late 1970s, just had to pass packets as they ar- created a new set of protocols, with they were forgotten. rived. Error correction and flow con- TCP for end-to-end error and flow With 1983’s “flag day”, TCP/IP trol could be handled at the edges of control and IP (which was sepa- had completely replaced NCP, and the network. He designed and built rated from TCP in Version 4) for the IP, began to see widespread use as a The need to grossly over-provision to avoid congestion in the Internet backbone allowed streams to work just well enough to catch on. network protocol. Around that time, Berkeley released a free, open source Berkeley Software Distribution Unix implementation of TCP/IP, including key applications. While rather crude, the price was right, subsidised by US tax dollars. And it provided for vendor-independent networking just as International Standards Organisa- tion’s Open Systems Interconnection (OSI) standards project was tearing itself apart from internet conflicts. TCP/IP’s strength was it worked for the current environment and was free. Moore’s Law allowed it to keep up with growth and covered up other holes. It easily handled the current applications, such as file and print services, although the World Wide Web provided a few bumps. But packet switching was designed to handle bursty data. IP was not optimised to support streaming. Disclaimer: Neither John Nolan or First Mile Net- IP has absorbed the glow from works have any association the Internet’s halo – but TCP/ whatsoever with the Pouzin IP has been a 30 year distraction from real internetworking. Society, apart from an aca- demic interest. Volume 5 Part 3 • 2011 | 43 node, and a route is thus a series of POAs. This makes multihoming almost useless, since each connec- tion has a different address. Routing should be to the node, not the POA. This mistake was perpetuated by the IETF in IP Version 6. The problem is magnified when dealing with multi- homed networks. Essentially, every backbone router needs to keep track of links to every network. Hundreds of thousands of them. Interconnec- tion between networks thus remains very sparse as it was in the 1980s. Network designers have to strike a balance between creating too many links, and thus overburdening the routers, and having too few links, and thus having to send local traffic on a very roundabout route. This doesn’t scale well at all. The more networks on the Internet, and the more multihomed provider-in- dependent address blocks, the more routes there are, and the number of possible paths thus rises faster than linearly. Oops. Add new demand from things, like “Smart Grid” that needs to multihome every meter, and it gets far worse. How does IPv6 handle this? By having a larger address space, it per- mits even more address blocks to exist. It doesn’t change the architec- ture; it just speeds up the fuel pump feeding the fire. IPv6 was designed to maintain the status quo. NAT IS YOUR FRIEND The TCP/IP ARPANET lacked any kind of security mechanisms, depending Network Address Translation (NAT) entirely on the security of the computers connected to it. is a controversial part of the TCP/IP world. It serves two major functions. The need to grossly over-provision (multihoming). By the 1980s, TCP/ It conserves IP addresses, and it adds to avoid congestion in the Internet IP was the most open protocol stack a layer of security. NAT is often seen backbone allowed streams to work but not the most powerful. as a layer violation because the NAT just well enough to catch on. Good And the Internet of today isn’t device has to modify the TCP and IP enough was the enemy of product the ARPANET of the 1970s or for layers together, changing port num- quality. The IP juggernaut was un- that matter the Internet of the early bers (in TCP or User Datagram Pro- stoppable. 1990s. There are many issues that IP tocol) as well as IP addresses. This doesn’t handle well and which could is not a problem with NAT per se. IP IP HAS A NUMBER OF WEAK- be addressed if a new protocol were address + port number is the con- NESSES TODAY developed from a clean slate, rather nection identifier. The two protocols The TCP/IP ARPANET itself had than as an extension of IP. TCP/IP should be viewed as being in same weaknesses that are surprising in a was a research project; let’s exploit layer. So address translation natu- network financed by national securi- the results of that research. rally deals with them together. NATs ty dollars. It lacked any kind of secu- only break broken architectures. rity mechanisms, depending entirely IP LACKS A COMPLETE AD- There is, of course, one clear layer on the security of the computers DRESSING ARCHITECTURE violation that NAT has to deal with, connected to it. (We see today how IP’s addressing architecture is in- but that’s not NAT’s fault either. well that worked out!) And it lacked complete. An IP address refers to Some application protocols put an IP support for redundant connections a point of attachment (POA), not a address inside the application layer 44 | Volume 5 Part 3 • 2011 THE JOURNAL OF THE INSTITUTE OF TELECOMMUNICATIONS PROFESSIONALS header. These have to be modified These offer the lossless assurance of by NAT, so a NAT has to understand bandwidth that IP, being connec- So if IP is so their syntax. This is rather like pass- tionless, lacks. Attempts to handle ing physical memory addresses in a streaming within IP are preposter- imperfect, can Java program. ously complex and unproven. (See, anything be done Another problem with TCP/IP is for instance, IMS, the IP Multimedia that the real name of an application Subsystem. It’s the nuclear fusion of about it? Of course is not the text form that humans type; IP: It’s always a few years from being … but it’s not going it’s an IP address and its well-known- ready.) port number. As if an application to be handled by name were a macro for a jump point A patH FORwaRD incremental upgrades through a well-known low memory So if IP is so imperfect, can anything address. When an application uses be done about it? Of course… but it’s or missteps like a host name or other text form such not going to be handled by incremen- IPv6. as a URI, the application resolves it tal upgrades or missteps like IPv6. by querying a Domain Name System Instead, what John Day has done in (DNS). Resolving names in the net- his Patterns in Network Architecture: work layer would provide a cleaner A Return to Fundamentals [1] is start which differ in policy and scope.