Network Architecture: Design Philosophies IS250 Spring 2010 John Chuang

John Chuang IS250 UC Berkeley2 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 Berkeley3 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 Berkeley4 ARPANET Design Philosophy  Fundamental goal: -“Effective multiplexed utilization of interconnected networks” -Q: what was alternative?  F undamental structure of the Internet: -“A packet switched communications facility in which a number of distinguishable networks are connected together using packet communications processors called gateways which implement a store and forward packet forwarding algorithm”

John Chuang IS250 UC Berkeley5 Packet Switching vs. Circuit Switching  “The technique selected for multiplexing was packet switching. An alternative such as circuit switching could have been considered, but the applications being supported, such as remote login, were naturally served by the packet switching paradigm”

John Chuang IS250 UC Berkeley6 Circuit Switching -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  Circuit switching used in traditional telephony:

John Chuang IS250 UC Berkeley7 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 Berkeley8 Packet Switching vs. Circuit Switching: Example  1Mbps link  Each user: -sends 100kbps when active -active 10% of the time  Circuit-switching: support 10 users  Packet-switching: with 35 users, probability[>10 active users] < Mbps N users

John Chuang IS250 UC Berkeley9 Packet Switching vs. Circuit Switching  Packet switching great for bursty data  Network congestion may result in packet delay and loss -Mechanisms for reliable data transfer, congestion control needed -Packet delay and loss  jitter  Challenge: how to support audio/video applications over packet-switched network (e.g., Skype, YouTube)?

John Chuang IS250 UC Berkeley10 Packet Switching vs. Circuit Switching  “The technique selected for multiplexing was packet switching. An alternative such as circuit switching could have been considered, but the applications being supported, such as remote login, were naturally served by the packet switching paradigm”

John Chuang IS250 UC Berkeley11 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 Berkeley12 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 Berkeley13 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 Berkeley14 End-to-End Argument  In a layered architecture, how do you divide functionality across the layers? Appl Trans port Net work Link Net work Link Net work Link Appl Trans port Net work Link Host AHost BRouter 1Router 2 end-to-end point-to-point end-to-end

John Chuang IS250 UC Berkeley15 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 Berkeley16 Tussle in Cyberspace  Design principles -Design for variation in outcome -Modularize design along tussle boundaries -Design for choice

John Chuang IS250 UC Berkeley17 Tussle in Cyberspace  Design Implications -Choice often requires open interfaces -Tussles often happen across interfaces -Visible exchange of value -Exposure of cost of choice -Visibility (or not) of choice -Tools to resolve and isolate faults and failures -It matters if the consequence of choice is visible -Tussles have different flavors -Tussles evolve over time -There is no such thing as value-neutral design -Don’t assume that you design the answer

John Chuang IS250 UC Berkeley18 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 Berkeley19 Redesigning the Internet  Why? What’s wrong with the current Internet?