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/ 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 . 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 . The original ARPANET protocol, (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, , 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 allowed streams to work just well enough to catch on.

network protocol. Around that time, Berkeley released a free, open source Berkeley Software Distribution 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 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 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 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 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. mechanism for applications to find afresh, taking into account lessons This alternation reflects a repeating each other. learned in the 35 years of TCP/IP’s unit consistent with interprocess In fact, even host names should existence, as well as the lessons of communication. The error and flow not be used in the application. Appli- the 1980s’ failed OSI program, and control function breaks up into two cations, not hosts, should be what’s the lessons of other network technol- functions, data transfer, which trans- named. The host simply hosts it. ogies of the past few decades. He has fers data, and data transfer control, Many applications nowadays run on made some key observations that which provides feedback from the more than one host. A popular ap- point to a new direction. receiver (ack and flow control). plication might run on thousands of OSI’s famous 7-layer reference The defining characteristic of hosts distributed worldwide (think model was defined too early, and a layer in networks is distributed Google). This requires a royal kludge incorrectly separated out Layers 5, 6 shared state of a given scope. More in the TCP/IP architecture and 7, which should have been one than one protocol may exist within layer, while there were potentially a layer, but layers should be opaque IP is poorly suited for 7 layers below the application. But to one another. All layers do the streaming fixed protocol stacks themselves turn same thing for a different range of IP was designed to deliver packets out to be the problem! The pattern the problem. By separating policy on a “best efforts” basis, meaning that Day noted is that protocol func- from mechanism, the same protocol that it’s okay to throw packets away. tions are repeated in different layers, mechanism can work across wide That’s not a bad thing. But it works best when the payload can use re- transmission. Streaming means that there’s no time to retransmit, so the stream must have low loss. The best that IP can do for streaming is to assign priorities, with high priority given to streams, such as telephone calls. When a packet is lost, ordinary data using TCP slows down; streams do not. So if there are too many streams on a link, ordinary data can be crowded out. We already have a telephone network and cable TV; these applications could potentially break the unique capabilities that only the Internet can provide. The telephone industry is evolving to- wards the use of IP, but it is a tricky proposition. Telephone streams often have to be separated at a lower layer, Connection-orientated services are better for deterministic traffic while put into separate flows using MPLS, connectionless is ideal for stochastic traffic Carrier , or some other tech- nique, even Time Division Multiplex.

Volume 5 Part 3 • 2011 | 45 protocol stack. There is thus no need for purpose-built protocols for each layer. There is not a fixed number of layers in the stack. The number of layers in any given network is vari- Figure 1: DIFs may be stacked as required. The number of layers in the stack able. There are simply as many as may vary from hop to hop needed, no more, no less. But any given system only has as many lay- ers as it has in a current system to- day (see Figure 1). The actual depth Shortest cycle time : IPC Langest cycle time : IPC of the stack is essentially invisible. Transfer IPC Control Management Because the same group of pro- tocols is used repeatedly, the imple- Delimiting mentation is simpler than the TCP/ Other Data Resource IP stack. Because the layers recurse, mgmt Routing DTP transfer DTCP alloc’n and can scale to form a large inter- stack Resource functions vector Information net, the protocol suite that supports Base the concept from Patterns in Network Relaying & Architecture is called the Recursive Multiplexing Internetwork Architecture (RINA). Common Distributed A RINA layer contains two pro- Protocol control Application Protocol (checksums, tocols, the Error and Flow Control enartotuib) added Protocol (EFCP) and the Common DTSV RIB Distributed Application Protocol (CDAP). These are, in fact, the only two protocols in RINA and Figure 2 Figure 2: Functions are executed within a DIF over different time scales shows these protocols and the asso- ciated functions. EFCP includes sub- parts, the first being the Data Trans- fer Protocol (DTP) which contains Host 1 Host 2 addressing, fragmentation and pro- Appllcation Appllcation process process tection information (checksum and Relaying time-to-live counter), and the second element Appllcation being the Data Transfer Control Pro- protocol Relay-and-mux Appllcation instances protocol tocol (DTCP) which sends feedback Port ID Port ID from destination to source. Note that IPC IPC Relaying IPC the DTP’s payload exists outside of process process application process Mux Mux the layer, while the DTCP operates entirely within that black box. Routing (relaying) is just an appli- IPC IPC IPC IPC cation (see Figure 3), and the basic process process process process layer mechanism is called a Distrib- uted IPC Facility, or DIF. It is a black Physlcal lnk Physlcal lnk box that operates among multiple systems; the IPC process thus runs Figure 3: A router is a DIF which performs relaying between DIFs as its on every system that belongs to application. the DIF. A DIF enforces strict layer boundaries: what happens inside the DIF is not visible outside of the DIF; ranges of scope, QoS, and band- computer is quite simple; it could what is visible at the top of a DIF width. Lower layers thus to do the just take the form of memory shared is the service requested of the DIF; same things as upper layers. Near between two processes. IPC between what is visible at the bottom is the the bottom, their characteristics are computers requires additional mech- service requested by the DIF of the dominated by the media; further up anisms to deal with issues such as DIF beneath it, if it isn’t the bottom it is the applications that dominate. reliability of communications and one. synchronisation. That’s where net- Each DIF identifies the DIF or ap- Recursive layers work protocols come in. plication above it by name. A DIF Networking is just interprocess com- This leads to the first principle of can span many systems; it may rely munications (IPC); ultimately all our proposed new network architec- on the services of lower-layer DIFs networking is communication be- ture: Layers are recursive. The same to link the members of the DIF. And tween processes. IPC within a single protocol can be used repeatedly in a these DIFs may in turn rely on DIFs

46 | Volume 5 Part 3 • 2011 THE JOURNAL OF THE INSTITUTE OF TELECOMMUNICATIONS PROFESSIONALS beneath them, transparent to the ap- plication processes that use them. One of the capabilities of the DIF is the optional encryption. The DIF itself is a securable container; thus the need for firewalls has been elimi- nated. Service Data Unit protection is available at the bottom of every layer. Hence there is no need for a separate RINA equivalent of IPsec ( Security) or SSL (Secure Socket Layer). Deep packet inspection is thus impossible and ir- relevant. Network content is thus in- herently neutral, though not in the “one size fits all” sense desired by many IP neutrality advocates. EFCP is based on Richard Watson’s 1978 work that proves the necessary and sufficient condition for reliable transfer is to bound three timers. It does not require a connection set-up or tear-down for integrity purposes, like TCP’s SYN and FIN. In fact, TCP uses the same three timers! So RINA lacks unnecessary overhead. Syn- RINA benefits include improved scalability and security – in terms of chronisation and port allocation are both privacy of communications and protection against attack distinct functions. This improves and simplifies security. Just as there are patterns visible in networking functions of the day, and Integrating connection- the other layers, it has become clear was not intended to support VoIP less and connection- that only six fundamental operations and IPTV which rely on substantial oriented networking can be performed remotely: Create/ over-provisioning. The work that led One of the reasons that many TCP/ delete, read/write, and start/stop to RINA began by asking the ques- IP backers are so passionate about to objects external to the protocol. tion, why do all of these protocols their cause is that they fought hard Hence it is clear that only one appli- look so much alike? battles over it. Connectionless ser- cation protocol is required. RINA has Investigation showed that there vice is fine for many things; the TCP/ adapted a previously existing proto- were a small number of mecha- IP Internet is an existence proof that col (CMIP - Common Management nisms in a protocol that had poli- it works, something that the backers Information Protocol) and renamed cies. For example, acknowledgement of the OSI connection-oriented net- it CDAP, or Common Distributed Ap- is a mechanism, but when to ask is work service (CONS), based on X.25, plication Protocol. policy. Recognising that differences would not have believed possible. What changes from application to in syntax were minimal, it became But as it turns out, the distinction be- application are in the objects being clear that ultimately there was only tween the two is less than it seems. manipulated, not the protocol. The one data transfer protocol. The en- The usual argument for connection- applications themselves are outside tire range could be accommodated less networking is simplicity. By not of the protocol, while data transfer by different policies. promising too much, the network is takes place within it. So the protocol A DIF can be asked to provide a remains stable, while new applica- low-loss connection for a specified tions are accommodated easily by level of capacity, such as might be re- Mobility is changing the object models. CDAP quired for an audio or video stream. is also used within the DIF for layer Or it can be asked for a best-effort obviously nothing management functions, including (unspecified QoS) connection. RINA more than dynamic enrollment (joining the DIF) and se- simply considers QoS to be a set of curity management, port allocation, parameters plugged in to the DIF, multi-homing, i.e. access control, QoS monitoring, flow and the specific mechanisms that it changing points of management, and routing. uses to provide it are an implementa- tion detail, hidden inside the black attachment more Designed for multiple box. If the DIF determines that it often than usual. functions can’t deliver the requested QoS, it TCP/IP was designed for the data rejects the request.

Volume 5 Part 3 • 2011 | 47 M M M IP addresses. The most obvious form of reference, of course, is unicast, an application resident in a single place. B (N)-DIF No known network architectures name hosts. There is a sloppy use of A (N-1)-DIF language that gives this impression but it is not true. (N-2)-DIF An application can live in one place, which is addressed via unicast. But often an application resides on Figure 4: As a mobile host moves, it joins new DIF and drops its more than one host. Popular web sites participation in old ones are redirected, invisible to the user. In so doing, they are simulating a second simpler, or “stupid”. A protocol has by DNS. This decouples the service type of address, anycast. Any one of been considered connection-oriented from an IP address. a set of destinations can serve the re- if it needs to set up a context for the The 32-bit IPv4 address was more quest. (Once a dialog is established flow of data. IP is considered con- than adequate for the ARPANET. It between two hosts this way, it is like- nectionless because each packet is would have been sufficient forever. ly to be completed via unicast.) The just routed as it comes along. IPv6 “fixes” the shortage of addresses third case is multicast, in which the But wait: How does a connection- by putting a 128-bit source and desti- information is relayed to every mem- less (IP) router know where to route nation address in every packet. This ber of a set of destinations. packets to? We’ve already deter- simply perpetuates IP’s architectural Multicast and anycast turn out to mined that an IP address doesn’t ac- flaws. One of the more surprising be subsets of a single form, whatever- tually tell you where it’s going; it just results from the theory underlying cast. Both deal with a set of addresses names the destination network and RINA is that a global address space and a rule. Anycast addresses one interface. So in fact connectionless is unnecessary. Limits of space do not member while multicast returns all routers require more context than permit a full explanation, but it fairly members that satisfy the rule. Hence connection-oriented ones because apparent that a 32-bit address is more unicast can be seen as the special case, they need to maintain, in effect, con- than enough for any layer. one where the set has a single mem- nections to every other node on the In RINA, applications are accessed ber. Thus applications need do noth- Internet! That’s what routing tables by name, and only by name. An ap- ing special to deal with multicast or are all about, and why they’re get- plication name names the applica- anycast. Just how a DIF implements ting bigger by the day. tion, not a path to it as in the current whatevercast is an internal matter, of Connectionless services are more Internet. Since a DIF is a Distributed course, since it’s a black box. robust to failures, while connection- Application that does IPC, they also The value of efficient multicast oriented services are more brittle to have names. is obvious in the case of streaming failure. Each is good in its proper The members of a DIF are applica- video, which can be sent to a set of place: Connectionless is ideal for tion processes (referred to as IPC Pro- destinations. This set can be dynam- stochastic traffic; connections are cesses) and hence have application ic: When a user wants to watch the better for a deterministic traffic. names. Addresses are simply syn- stream, the set top box, smartphone RINA achieves a unification of the onyms for IPC Processes taken from or computer is immediately enrolled connection/connectionless models. a name space whose scope is limited in the multicast set. Only one copy This sometimes is manifested as con- to the DIF, and may be structured to of the stream is relayed to any given nectionless within a subnet but con- make them more useful within the DIF, though that DIF may use its mul- nections over the subnet. DIF. Addresses are only known by ticast capability to relay the stream to members of the DIF, not the user ap- as many other DIFs as necessary to Names are global, ad- plications. Since addresses are often reach the members of the set. This is dresses local location-dependent with in the DIF, far more efficient than IPTV in which Addressing in the Internet defines a they must be assigned by the DIF - path from the interface to the appli- it is the only one who knows where cation (IP address plus well-known they are. Since addresses name where port). DNS is merely a human- the relaying is done, multi-homing is Adopting RINA friendly macro for the IP address. a consequence of the structure. Mo- should be easier than One of the newest major protocols in bility is obviously nothing more than the TCP/IP suite, HTTP - Hypertext dynamic multi-homing, i.e. changing following the IETF’s Transfer Protocol (invented in 1989), points of attachment more often than recommendations to tries to improve upon this; the ac- usual (see Figure 4). tual URL (Uniform Resource Loca- transition from IPv4 ter) string, a name, is transmitted to Unicast, multicast, and to IPv6. the web server, even as the IP layer anycast uses the numeric address returned RINA names are more flexible than

48 | Volume 5 Part 3 • 2011 THE JOURNAL OF THE INSTITUTE OF TELECOMMUNICATIONS PROFESSIONALS every viewer is watching its own QoS options without allowing deep that will facilitate lower cost, high- stream from a server. It could even packet inspection or even making er-efficiency implementations. By provide a practical way for cable TV the application visible to an under- returning to the fundamentals and to evolve to a common structure with lying network. It provides an easy recognising the patterns in network the Internet itself. adoption path for IPv4 users. And it architecture, RINA promises to move does all this with a radical simplicity networking to the next level. Easier adoption than IPv6 RINA can only be of practical use if Afterword from John Nolan it can work with TCP/IP, at least ini- tially. In fact, adopting RINA should Goldstein and Day’s paper is but a brief introduction to RINA, with be easier than following the IETF’s Day’s book an excellent read should the reader wish to delve further2. recommendations to transition from One of the questions that the work of the Pouzin Society raises for me IPv4 to IPv6. That’s difficult at best. is whether there is another “ contender”3 but I’m not so sure if there is? IPv6 was not designed for backward There is no doubt that the TCP/IP protocol suite is now fully established or forward compatibility with its and as an example “IPv6 day4” has been and gone [3]. Continuing on the predecessor. They occupy the same lack of alternatives and in a recent edition of the aforementioned IP Jour- place in a fixed protocol stack. nal [4], Geoff Huston (co-editor for the edition) states under “Myth 8” RINA provides more options for that “no viable substitutes exist.” I’m guessing that the principal authors its phased adoption. It is not fixed of this paper may disagree with that statement? to one place in the protocol stack, So is the TCP/IP protocol suite dancing its Last Waltz and if so, is RINA so implementations can be flexible. the only alternative? I’m keeping an open mind (as I don’t know the It treats TCP/IP as a sort of limited answer), but I would encourage readers to get involved, particularly as DIF. RINA thus can be applied below the concepts underpinning RINA has certainly challenged my thinking. TCP/IP, to provide network service Perhaps we are too heavily entrenched with the TCP/IP protocol suite to to TCP/IP hosts, or to connect IP net- have an open and honest debate - time will tell? works. RINA can be used above IP, using existing IP links as a transport medium. And RINA networks can Abbreviations be gatewayed to TCP/IP networks, translating at least some applications ARPANET Advanced Research Projects Agency Network between the two. CDAP Common Distributed Application Protocol Bottom line: The adoption of RINA DIF Distributed IPC Facility is seamless. Internet applications on DNS Domain Name System a RINA DIF can be accessed transpar- DTCP Data Transfer Control Protocol ently from the Internet and vice versa. DTP Data Transfer Protocol RINA, as it becomes available, EFCP Error and Flow Control Protocol can thus gradually supplant TCP/IP. IETF Internet Engineering Task Force A backbone network could be built IP Internet Protocol using RINA, supporting both types IPC Interprocess Communications of upper layers. And RINA-native ap- plications could be developed and ISO International Standards Organisation rolled out. Since RINA does not de- MPLS Multi Protocol Label Switching pend on globally-unique IP address- NAT Network Address Translation es, a single IP address could function NCP Network Control Program as a gateway to a RINA network in OSI Open Systems Interconnection which applications communicate us- POA Point Of Attachment ing names. QoS Quality of Service RINA Recursive Internetwork Architecture Summary of benefits TCP Transmission Control Protocol It can be seen that RINA offers a number of benefits compared to TCP/ IP. These include improved scalabil- FOOTNOTES ity (the ability to efficiently support larger networks) and security (both 1 This paper has been abridged by Fred Goldstein from the original paper, privacy of communications and pro- which can be found at [5] tection against attack). It addresses 2 If only to relive some of the historical moments and to gain an insight into the “3M” challenges of mobility, the political discussions during the “protocol wars.” multicasting and multi-homing. It 3 During the protocol wars, I can recall OSI vs. TCP/IP vs. SNA with Decnet provides a standard mechanism for another player at the time. application development. It solves 4 For a European perspective on IPv6 day see the comments from RIPE [6]. the neutrality issue by providing

Volume 5 Part 3 • 2011 | 49 About the authors References 1. http://www.cisco.com/web/ John Day has been involved in research and about/ac123/ac147/about_ y development of computer networks since 1970, cisco_the_internet_protocol_ when they were the 12th node on ARPANET journal.html. [Online] and has developed and designed protocols for 2. http://www.pouzinsociety.org/. everything from the data link layer to the appli- [Online] John Da cation layer. Also making fundamental contri- 3. http://www.worldipv6day.org/. butions to research on distributed databases. He [Online] managed the development of the OSI reference 4. http://www.cisco.com/web/ model, naming and addressing, and a major contributor to the about/ac123/ac147/archived_ upper-layer architecture. He was a major contributor to the issues/ipj_14-1/141_myths.html. development of network management architecture, working [Online] in the area since 1984 and building and deploying a network management system, a decade ahead of comparable systems. 5. http://pouzin.pnanetworks. John has published Patterns in Network Architecture: A Return com/images/PSOC- to Fundamentals, which has been characterised (embarrass- MovingBeyondTCP.pdf. [Online] ingly) as “the most important book on network protocols in 6. http://labs.ripe.net/Members/ general and the Internet in particular ever written.” John is emileaben/measuring-world- also a recognised scholar in the history of cartography, and -day-glitches-and-lessons- contributed to exhibits at the Smithsonian. He can be contact- learned. [Online] ed at [email protected]

Fred Goldstein advises companies on technical, regulatory and business issues related to the telecommunications, cable, wireless and Internet industries, especially in areas where they overlap. He assists service providers in network design, business modelling, planning, and technical architecture. He has frequently been an expert witness in intercarrier com- pensation and network interconnection cases. He has worked with enterprise networks on a wide range of matters such as backbone network design, voice systems planning, and traffic

Fred G olds t e i n engineering. The author of numerous articles including The Great Telecom Meltdown and ISDN In Perspective, he has served on standards committees in areas such as ATM networks and Frame Relay, and has taught courses for Northeastern University and National Technological Univer- sity. He can be contacted at [email protected]

John Nolan has been active in the telecoms industry since 1971 and after leaving BT in 1979 he spent extensive periods in senior telecom roles in both Local Government (GLC/ILEA) and subsequently, the Financial Services industry (NatWest Bank Group). In 1995, he joined Intercai Mondiale (www.intercai.co.uk) where he was lucky enough to enjoy many differ- ing cultures whilst consulting in Europe, the USA, and the Middle and Far East. In 2003, he

John N ol a n left Intercai Mondiale and co-founded First Mile Networks (www.firstmilenetworks.co.uk) with Dr Chris Lilly. John has a degree in Electrical and Electronic Engineering from London South Bank University and is a member of the Institution of Engineering and Technology; a member of the Institute of Electrical and Electronics Engineers; and is also a member of the Association for Computing Machinery. He can be contacted at [email protected].

Call for Papers

Authors are encouraged to submit articles for publication in The Journal. Interested parties should e-mail [email protected] in the first instance with topic suggestions.

50 | Volume 5 Part 3 • 2011