170 likes | 228 Views
Network Architecture: Design Philosophies. IS250 Spring 2010 John Chuang chuang@ischool.berkeley.edu. Outline. Design philosophy of ARPANET Packet switching versus circuit switching End-to-end design principle Tussles in cyberspace Re-designing the Internet. History of the Internet.
E N D
Network Architecture:Design Philosophies IS250 Spring 2010 John Chuang chuang@ischool.berkeley.edu
Outline • Design philosophy of ARPANET • Packet switching versus circuit switching • End-to-end design principle • Tussles in cyberspace • Re-designing the Internet John Chuang IS250 UC Berkeley
History of the Internet 1961: Leonard Kleinrock: queuing theory shows effectiveness of packet switching 1969: Dept. of Defense (ARPA) sponsors the development of a packet-switched network, called the ARPANET. First four nodes at UCLA, SRI, Utah, UCSB. 1974: Vint Cerf and Bob Kahn proposes TCP/IP. 1983: ARPANET adopts TCP/IP. At this time, the ARPANET has 200 routers. 1984: National Science Foundation (NSF) funds a TCP/IP based backbone network. This backbone grows into the NSFNET, which becomes the successor of the ARPANET. 1995: NSF stops funding of NSFNET. The Internet is completely commercial. John Chuang IS250 UC Berkeley
ARPANET Design Philosophy • Fundamental goal: • “Effective multiplexed utilization of interconnected networks” • Q: what was alternative? • Fundamentalstructure of the Internet: • “A packet switched communications facility in which a number of distinguishablenetworks are connected together using packet communications processors called gateways which implement astore and forward packet forwarding algorithm” John Chuang IS250 UC Berkeley
Packet Switching vs. Circuit Switching • “The technique selected for multiplexing was packetswitching. An alternative such as circuit switching couldhave been considered, but the applications beingsupported, such as remote login, were naturally servedby the packet switching paradigm” John Chuang IS250 UC Berkeley
Circuit Switching • Circuit switching used in traditional telephony: • Requires establishment and teardown of circuit • Fixed bandwidth resources (e.g., 64kbps for voice channel) dedicated to each call, even if actual data transmission rate is lower • Not efficient for ‘bursty’ traffic sources • Low jitter (delay variations) important for real-time applications John Chuang IS250 UC Berkeley
Packet Switching • Data transmitted in small packets • Single message may be split into multiple packets • Every packet contains full control info (e.g., destination address) in header • Packets may take different paths • Packets may arrive out of order • Packets may be lost or corrupted (need recovery mechanism) • Statistical multiplexing possible • Works well with ‘bursty’ traffic John Chuang IS250 UC Berkeley
Packet Switching vs. Circuit Switching • “The technique selected for multiplexing was packetswitching. An alternative such as circuit switching couldhave been considered, but the applications beingsupported, such as remote login, were naturally servedby the packet switching paradigm” John Chuang IS250 UC Berkeley
ARPANET Design Goals • Fundamental goal: • Effective multiplexed utilization of interconnected networks • Second level goals: • Survivability • Support multiple types of service • Accommodate variety of networks • Permit distributed management of resources • Cost effective • Host attachment with low level of effort • Resource accountability John Chuang IS250 UC Berkeley
Discussion • Did the ordering of the goals matter? • What does ‘fate-sharing’ mean? • What does ‘stateless packet switches’ mean? • Can you think of additional goals not present in the original list? John Chuang IS250 UC Berkeley
End-to-End Argument • What is the E2E argument? • What is the connection between the E2E argument and “fate-sharing” and “stateless switches”? John Chuang IS250 UC Berkeley
Appl Appl end-to-end Trans port Trans port end-to-end Net work Net work Net work Net work point-to-point Link Link Link Link point-to-point Host A Router 1 Router 2 Host B End-to-End Argument • In a layered architecture, how do you divide functionality across the layers? John Chuang IS250 UC Berkeley
End-to-End Argument • Think twice (or thrice) about implementing a functionality that you think is useful for an application at a lower layer • What are the reasons for implementing a functionality at a lower layer? • What are the costs/pitfalls of implementing a functionality at a lower layer? • How is the E2E argument reflected (or not) in the TCP/IP architecture? John Chuang IS250 UC Berkeley
Tussle in Cyberspace • Design principles • Design for variation in outcome • Modularize design along tussle boundaries • Design for choice John Chuang IS250 UC Berkeley
Tussle Spaces • Economics • Consumer choice necessary for competition • Address portability (minimize switching cost) • Value pricing (market segmentation; price discrimination) • Open access • User-directed routing • Trust • Where to implement what functionality? • Who decides on policy? • Identity • Innovation • Openness to innovation (E2E) • Incentives for innovation (user choice) John Chuang IS250 UC Berkeley
Redesigning the Internet • Why? What’s wrong with the current Internet? John Chuang IS250 UC Berkeley