The Design Philosophy of the DARPA Internet Protocols [Clark 1988]

1. CS244 Winter 2013 Lecture 2 Architecture and Principles The Design Philosophy of the DARPA Internet Protocols [Clark 1988] Sachin Katti

2. Computer Comms & Packet Switching ARPA: 1957, in response to Sputnik Paul Baran • Early 1960s: New approaches for survivable comms systems; “hot potato routing” and decentralized architecture, 1964 paper Donald Davies, early 1960s • Coins the term “packet” Len Kleinrock (MIT thesis): “Information flow in large communication nets”, 1961 J. Licklider & W. Clark (MIT), On-line Man Computer Communication L. Roberts (MIT), first ARPANET plan for time-sharing remote computers, SOSP ‘67 paper

3. ARPANET & Internetworking ARPANet • 1967: Connect computers at key research sites across the US using pt-to-pt telephone lines • Interface Message Processors (IMP) ARPA contract to BBN • Ted Kennedy telegram on BBN getting contract • Interfaith Message Processor! BBN team that implemented the interface message processor

4. ARPANET Topology in 1969 First inter-site demo, 1969. First crash very soon after!

5. History, contd. • 1972, modified ARPANET email program (BBN), various demos and apps; CYCLADES effort in France; telnet spec • 1973, APRANET becomes international • 1973-75, internetworking effort (Kahn & Cerf, et al.) • 1976, UUCP distributed by AT&T • 1978, TCP and IP split (end-to-end principle) • 1980, ARPANET grinds to halt due to a virus

6. Context: David D. Clark (MIT) • Chief Protocol Architect for the Internet from 1981. • Continues to be a network visionary today. • At the time of writing (1987)… • (Almost) no commercial Internet • 1 yr after Cisco’s 1st product, IETF started • Number of hosts reaches 10,000 • NSFNET backbone 1 year old; 1.5Mb/s

7. What you said • Graham Roth: "I guess I've been assuming for some time that a datagram service is the end result of extensive research and provides the best service overall, and was therefore, in the end the natural choice."

8. The Design Philosophy of the DARPA Internet Protocols [Clark 1988] Goal 0: An “effective” technique for multiplexed utilization of existing interconnected networks. Goal 1: Internet communication must continue despite loss of networks or gateways. Goal 2: The Internet must support multiple types of communication service. Goal 3: The Internet architecture must accommodate a variety of networks [underneath]. Goal 4: The Internet architecture must permit distributed management of its resources. Goal 5: The Internet architecture must be cost effective. Goal 6: The Internet architecture must permit host attachment with a low level of effort. Goal 7: The resources used in the internet architecture must be accountable.

9. What you said • Richard Hsu: "With hindsight, it is surprising that privacy was never a goal in the design process especially when the original context of the project was of a military context. With hostile environments and sensitive military communication, security should have been one of the top priorities. It is understandable that there could have been a need for a complete oversight of communication, but in reality privacy seems like it should outweigh the need for an omniscient view of Internet traffic. " • Chirag Sangani: A problem with the original design the author alludes to, but does not explore fully, is the issue of network security. […] Indeed, the problem is more severe – if a host misbehaves with malicious intent – it could compromise the confidentiality of data traversing the network, or the integrity of the network itself. This has proven to be a serious issue of late, and the model of a trustworthy host, as has been assumed by the author, is simply not realistic.

10. Goal 0: An effective technique for multiplexed utilization of existing interconnected networks Led to: Different networks connected together by packet switched, store-and-forward routers/gateways Q. Why interconnect existing networks and not design a new overall network from scratch? Q. Why was packet switching picked for multiplexing? What were the choices?

11. What you said • Wei Shi: For the first goal, I think it is true when the paper is right, and it is still true after 20 years. We have many more flavors of networks than 20 years ago, for example, WiFi and cellular. The Internet has been able to connect all of those new networks seamlessly. For the second goal, I think it’s true in theory, but in reality we encounter disconnections even without the total partition, because the infrastructure relies on many manual configuration such as routing table. Although there may exist a path between 2 hosts, the router may not know given the size of the Internet.

12. Goal 1: Internet communication must continue despite loss of networks or gateways. • “Entities should be able to continue communicating without having to reestablish or reset the high level state of their conversation.” • “The architecture [should] mask completely any transient failure.” Leads to: • “Fate-sharing” model - only lose communication state if the end-host is lost. • Stateless packets switches => datagrams Q. What alternative design could there be? Q. How does the Internet do this? Q. Would a “dedicated” new network be more reliable?

13. What you said? • Khaled AlTurkestani: As a side note, I found it interesting is that Clark did not mention the end-to-end principle, which he coined (along with others) before he published this paper, and which was a product of the Internet properties of statelessness and best-effort delivery

14. Other goals Goal 4: The Internet architecture must permit distributed management of its resources Q. Does it accomplish this? Goal 5: The Internet architecture must be cost effective. Q. Is it cost effective? Goal 7: The resources… must be accountable Q. What does this mean? Q. What would such a network look like?

15. What you said • Vikas Yendluri: I think Clark makes a good point about why knowledge of flows (connection state) is useful for purposes of accountability. But it seems that in recent years, router manufacturers have been sniffing TCP headers to monitor flow information themselves.

16. Minimum Assumptions of interconnected networks • Can transport a datagram • …of reasonable size • …with reasonable chance of delivery Interesting comments: Reliability and qualities of service were not built in because they would require too much change. Datagram as a building block, not as a service.

17. Other discussion questions • Originally TCP+IP were joined, but were later split. Why was that? • “It proved more difficult than first hoped to provide multiple types of service without explicit support from the underlying network” Q. Why is that? What has happened since?

18. Other discussion questions Interesting comment:“The most important change in the Internet…will probably be the development of a new generation of tools for management of resources...” Q. Has this happened?

19. Author’s conclusion • “Datagram” good for most important goals, but poor for the rest of the goals. • Processing packets in isolation, resource management, accountability all hard. • Anticipates flows and “soft-state”for the future.