2. winter 2008 Internet Design1 The Internet Global scale, general purpose, heterogeneous-technologies, public, computer network Internet Protocol –Open standard: Internet Engineering Task Force (IETF) as standard body ( http://www.ietf.org )http://www.ietf.org –Technical basis for other types of networks Intranet: enterprise IP network Developed by the research community

3. winter 2008 Internet Design2 Services Provided by the Internet Shared access to computing resources –Telnet (1970’s) Shared access to data/files –FTP, NFS, AFS (1980’s) Communication medium over which people interact –Email (1980’s), on-line chat rooms (1990’s) –Instant messaging, IP Telephony (2000’s) A medium for information dissemination –USENET (1980’s) –WWW (1990’s) Replacing newspaper, magazine –Audio, video (2000’s): peer-to-peer systems Replacing radio, telephony, TV, …

4. winter 2008 Internet Design3 Origin of Internet? Started by U.S. research/military organizations: Three Major Actors: –DARPA: Defense Advanced Research Projects Agency funds technology with military goals –DoD: U.S. Department of Defense early adaptor of Internet technology for production use –NSF: National Science Foundation funds university

5. winter 2008 Internet Design4 Brief History of the Internet 70’s: started as a research project, 56 kbps, < 100 computers 80-83: ARPANET and MILNET split, 85-86: NSF builds NSFNET as backbone, links 6 Supercomputer centers, 1.5 Mbps, 10,000 computers 87-90: link regional networks, NSI (NASA), ESNet(DOE), DARTnet, TWBNet (DARPA), 100,000 computers 90-92: NSFNET moves to 45 Mbps, 16 mid-level networks 94: NSF backbone dismantled, multiple private backbones Today: backbones run at >10 Gbps, >300 millions computers in 150 countries

6. winter 2008 Internet Design5 Time Line of the Internet Source: Internet Society

7. winter 2008 Internet Design6 Growth of the Internet Number of Hosts on the Internet: Aug. 1981 213 Oct. 1984 1,024 Dec. 1987 28,174 Oct. 1990 313,000 Oct. 1993 2,056,000 Apr. 1995 5,706,000 Jan. 1997 16,146,000 Jan. 1999 56,218,000 Jan. 2001 109,374,000 Jan. 2003 171,638,297 Jul 2004 285,139,107 Jul 2005 353,284,187

8. winter 2008 Internet Design7 Today’s Internet LANs International lines ISP company university national network regional network NAP Internic on-line services company access via modem Internet: “networks of networks” at global scale! 3G cellular networks WiFi

9. winter 2008 Internet Design8 Internet Network Leveraging Sprint’s SONET-based, gigabit switch Internet backbone Private Peering Private Peering Private Peering MAE-West Exchange Point Pacific Bell Exchange Point Private Peering Ameritech Exchange Point Private Peering Private Peering Sprint Exchange Point Private Peering MAE-East Exchange Point Private Peering

10. winter 2008 Internet Design9 Sprint Network Click here for a closer look at the Sprint network on the East Coast Click here for a closer look at the Sprint network in Northern California Pearl City in Hawaii is a future network location Click here for a closer look at the Sprint network in Washington state Legend DS3 OC3 OC12 OC48 Seattle Atlanta Chicago Roachdale Stockton San Jose Anaheim Fort Worth Orlando Kansas City Cheyenne New York Pennsauken Relay Wash. DC Tacoma

11. winter 2008 Internet Design10 OC1 (45 Mbps), OC2 (155 Mbps), …, OC192 (10 Gbps)

12. winter 2008 Internet Design11 UUNET Global BackBone

13. winter 2008 Internet Design12 UUNET North America Backbone

14. winter 2008 Internet Design13 UUNET Europe

15. winter 2008 Internet Design14 Internet Structure: Network of Networks roughly hierarchical at center: “tier-1” ISPs (e.g., UUNet, BBN/Genuity, Sprint, AT&T), national/international coverage –treat each other as equals Tier 1 ISP Tier-1 providers interconnect (peer) privately NAP Tier-1 providers also interconnect at (public/private) Internet exchange points, or private peering links

16. winter 2008 Internet Design15 Internet Structure: Network of Networks “Tier-2” ISPs: smaller (often regional) ISPs –Connect to one or more tier-1 ISPs, possibly other tier-2 ISPs Tier 1 ISP IXP Tier-2 ISP Tier-2 ISP pays tier-1 ISP for connectivity to rest of Internet  tier-2 ISP is customer of tier-1 provider Tier-2 ISPs also peer privately with each other, interconnect at IXPs

17. winter 2008 Internet Design16 Internet Structure: Network of Networks “Tier-3” ISPs and local ISPs –last hop (“access”) network (closest to end systems) Tier 1 ISP NAP Tier-2 ISP local ISP local ISP local ISP local ISP local ISP Tier 3 ISP local ISP local ISP local ISP Local and tier- 3 ISPs are customers of higher tier ISPs connecting them to rest of Internet

18. winter 2008 Internet Design17 Internet Structure: Network of Networks a packet passes through many networks! Tier 1 ISP NAP Tier-2 ISP local ISP local ISP local ISP local ISP local ISP Tier 3 ISP local ISP local ISP local ISP Try a traceroute! host/network edge: IP addresses, port no’s network core: intra-domain vs. inter-domain routing

19. winter 2008 Internet Design18 Who Runs the Internet “nobody” really! standards: Internet Engineering Task Force (IETF) names/numbers: The Internet Corporation for Assigned Names and Numbers (ICANN) operational coordination: IEPG(Internet Engineering Planning Group) networks: ISPs (Internet Service Providers), NAPs (Network Access Points), …… fibers: telephone companies (mostly) content: companies, universities, governments, individuals, …;

20. winter 2008 Internet Design19 Internet “Governing” Bodies Internet Society (ISOC): membership organization –raise funds for IAB, IETF& IESG, elect IAB Internet Engineering Task Force (IETF): –a body of several thousands or more volunteers –organized in working groups (WGs) –meet three times a year + email Internet Architecture Board –architectural oversight, elected by ISOC Steering Group (IESG): approves standards, –Internet standards, subset of RFC RFC: “Request For Comments”, since 1969 –most are not standards, also experimental, informational and historic(al)

21. winter 2008 Internet Design20 Internet Names and Addresses Internet Assigned Number Authority (IANA): –keep track of numbers, delegates Internet address assignment –designates authority for each top-level domain InterNIC, gTLD-MOU, CORE: –hand out names –provide “root DNS service” RIPE, ARIN, APNIC: –hand out blocks of addresses Many responsibilities (e.g., those of IANA) are now taken over by the Internet Corporation for Assigned Names and Numbers (ICANN)

22. winter 2008 Internet Design21 Internet Hourglass Architecture

23. winter 2008 Internet Design22 Implications of Hourglass A single Internet layer module: Allows all networks to interoperate –all networks technologies that support IP can exchange packets Allows all applications to function on all networks –all applications that can run on IP can use any network Simultaneous developments above and below IP

24. winter 2008 Internet Design23 Internet Names and Addresses host and domain names other “names”: email addresses, URLs, … IP addresses: logical, with global reachability –IPv4: 32 bits, IPv6: 128 bits, “global” –two-level hierarchy: network part and host part CIDR: network prefixes, e.g., 128.101.0.0/24 –Network Address Translation (NAT) complicates global reachability MAC (and other physical-layer) addresses –used and understood by “native” physical technologies! According to Shoch (IEEE COMPCON’78) –name: identifies what you want –address: identifies where it is –route: identifies how to get there

25. winter 2008 Internet Design24 Internet Standardization Process All standards of the Internet are published as RFC But not all RFCs are Internet Standards A typical (but not only) way of standardization is: –Internet Drafts –RFC –Proposed Standard –Draft Standard (requires 2 working implementation) –Internet Standard (declared by IAB) David Clark, MIT 1992: “We reject: kings, presidents, and voting. We believe in: rough consensus and running code.”

26. winter 2008 Internet Design25 Internet Design: Big Picture Internet architectural, design and implementation principles –not “scriptures”, but guidelines –understand pros and cons, trade-offs involves Original Internet Design Goals –what contributed to the huge success? –what still amiss, biggest weaknesses? Internet as a case study –virtualization., layered architecture, end-to-end argument, soft-state, fate sharing, … Readings –See Reading List

27. winter 2008 Internet Design26 Architectural Principles (not unique to networks!) Zhi-Li’s version (synthesized from various sources) End-to-end argument –functionality placement Modularity –Increase inter-operability and manage complexity vertical partition -> layered architecture horizontal partition? Keep it simple, stupid (KISS principle) –Occam’s Razor: choose simplest among many solutions! complicated design increases system coupling (inter- dependence), amplifies errors,.. don’t over-optimize! Separating policies from mechanisms –decouple control from data –“semantics-free” Design for scale –hierarchy, aggregation, …

28. winter 2008 Internet Design27 Network Architecture What is (Network) Architecture? – not the implementation itself –“design blueprint” on how to “organize” implementations what interfaces are supported where functionality is implemented Two Basic Architectural Principles –Modularity (e.g., layering) how to break network functionality into modules –End-to-End Argument where to implement functionality

29. winter 2008 Internet Design28 Some Design/Implementation Principles virtualization indirection soft state vs. hard state fate sharing randomization expose faults, don’t suppress/ignore caching ……

30. winter 2008 Internet Design29 Original Internet Design Goals [Clark’88] 0 Connect existing networks –initially ARPANET and ARPA packet radio network 1.Survivability - ensure communication service even with network and router failures 2.Support multiple types of services 3.Must accommodate a variety of networks 4.Allow distributed management 5.Allow host attachment with a low level of effort 6.Be cost effective 7.Allow resource accountability In order of importance:

31. winter 2008 Internet Design30 Priorities The effects of the order of items in that list are still felt today –E.g., resource accounting is a hard, current research topic Different ordering of priorities would make a different architecture! How well has today’s Internet satisfied these goals? Let’s look at them in detail

32. winter 2008 Internet Design31 0. Connecting Existing Networks 1974: multiple unconnected networks –ARPAnet –data-over-cable networks –packet satellite network (Aloha) –packet radio network.. differing in: –addressing conventions (i.e., address formats) –packet formats and packet sizes –Performance: bandwidth, latency, loss rate, … –error recovery mechanisms –routing How to inter-network various (heterogeneous) network technologies?

33. winter 2008 Internet Design32 Cerf & Kahn: Interconnecting Two Networks “…interconnection must preserve intact the internal operation of each network.” “..the interface between networks must play a central role in the development of any network interconnection strategy. We give a special name to this interface that performs these functions and call it a GATEWAY.” “.. prefer that the interface be as simple and reliable as possible, and deal primarily with passing data between networks that use different packet-switching strategies “…address formats is a problem between networks because the local network addresses of TCP's may vary substantially in format and size. A uniform internetwork TCP address space, understood by each GATEWAY and TCP, is essential to routing and delivery of internetwork packets.” ARPAnet satellite net

34. winter 2008 Internet Design33 Design Alternatives Through translation/mapping: –Map one address format to another: nxn mappings –Difficulty in dealing with different features supported by networks –Scales poorly with # of network types, addition of new types Virtualization: –Provide one common format overlaid on top of “lower-level” addresses –Map lower level addresses to common format: nx1 and 1xn mappings role of ARP, encapsulation/decapsulation –Layering necessary but what info from “lower layer” (underlying “physical” networks) to hide, and what to expose!

35. winter 2008 Internet Design34 Gateway Alternative Translation –Difficulty in dealing with different features supported by networks –Scales poorly with number of network types (N^2 conversions) Standardization/Virtualization –“IP over everything” –Minimal assumptions about network –Hourglass design

36. winter 2008 Internet Design35 Design of Original Internet via Gateways (cf. Cerf and Kahn) ARPAnet satellite net Gateway: “embed internetwork packets in local packet format or extract them” route (at internetwork level) to next gateway gateway Internetwork layer: addressing: internetwork appears as a single, uniform entity, despite underlying local network heterogeneity network of networks

37. winter 2008 Internet Design36 Historical Aside: Proposed Internetwork packet in 1974: local header source address dest. address seq. # byte count flag field text checksum network TCP identifier 8 16

38. winter 2008 Internet Design37 Cerf & Kahn’s Internetwork Architecture What is virtualized? two layers of addressing: internetwork and local network new layer makes everything homogeneous at internetwork layer underlying local network technology (cable, satellite, 56K modem) is “invisible” at internetwork layer

39. winter 2008 Internet Design38 1. Survivability 1.As long as the network is not partitioned, two endpoints should be able to communicate 2.Failures (excepting network partition) should not interfere with endpoint semantics (why?) Maintain state only at end-points –Fate-sharing, eliminates network state restoration –stateless network architecture (no per-flow state) Routing state is held by network (why?) No failure information is given to ends (why?)

40. winter 2008 Internet Design39 Survivability (cont’d) If network disrupted and reconfigured: –Communicating entities (“end systems”) should not care! –No higher-level state reconfiguration How to achieve such reliability? –Where can communication state be stored? NetworkHost Failure handingReplication“Fate sharing” SwitchesMaintain stateStateless Host trustLessMore

41. winter 2008 Internet Design40 Fate Sharing Lose state information for an entity if (and only if?) the entity itself is lost. Examples: –OK to lose TCP state if one endpoint crashes NOT okay to lose if an intermediate router reboots –Is this still true in today’s network? NATs and firewalls Connection State State No State

42. winter 2008 Internet Design41 Soft-State Basic behavior –Announce state –Refresh state –Timeout state Penalty for timeout – poor performance Robust way to identify communication flows –Possible mechanism to provide non-best effort service Helps survivability

43. winter 2008 Internet Design42 End-to-End Argument Deals with where to place functionality –Inside the network (in switching elements) –At the edges Argument: –There are functions that can only be correctly implemented by the endpoints – do not try to completely implement these elsewhere

44. winter 2008 Internet Design43 Discussion Is there any need to implement reliability at lower layers? Yes, but only to improve performance If network is highly unreliable –Adding some level of reliability helps performance, not correctness –Don’t try to achieve perfect reliability! –Implementing a functionality at a lower level should have minimum performance impact on the applications that do not use the functionality

45. winter 2008 Internet Design44 Design Challenges and Trade-offs Install functions in network that aid application performance…. …without limiting the application flexibility of the network Trade-offs: –application has more information about the data and semantics of required service (e.g., can check only at the end of each data unit) –lower layer has more information about constraints in data transmission (e.g., packet size, error rate) Note: these trade-offs are a direct result of layering!

46. winter 2008 Internet Design45 Do These Belong in the Network? Multicast? Routing? Quality of Service (QoS)? Name resolution? (is DNS “in the network”?) Web caches?

47. winter 2008 Internet Design46 2. Types of Service Best effort delivery All packets are treated the same Relatively simple core network elements Building block from which other services (such as reliable data stream) can be built Contributes to scalability of network No QoS support assumed from below –Accommodates more networks –Hard to implement without network support –QoS is an ongoing debate…

48. winter 2008 Internet Design47 Types of Service (cont’d) TCP vs. UDP –Elastic apps that need reliability: remote login or email –Inelastic, loss-tolerant apps: real-time voice or video –Others in between, or with stronger requirements –Biggest cause of delay variation: reliable delivery Today’s net: ~100ms RTT Reliable delivery can add seconds. Original Internet model: “TCP/IP” one layer –First app was remote login… –But then came debugging, voice, etc. –These differences caused the layer split, added UDP

49. winter 2008 Internet Design48 3. Varieties of Networks Minimum set of assumptions for underlying net –Minimum packet size –Reasonable delivery odds, but not 100% –Some form of addressing unless point to point Important non-assumptions: –Perfect reliability –Broadcast, multicast –Priority handling of traffic –Internal knowledge of delays, speeds, failures, etc. Much engineering then only has to be done once

50. winter 2008 Internet Design49 The “Other” goals 4. Management –Each network owned and managed separately –Will see this in BGP routing especially 5. Attaching a host –Not awful; DHCP and related autoconfiguration technologies helping. 6. Cost effectiveness –Economies of scale won out –Internet cheaper than most dedicated networks –Packet overhead less important by the year But…

51. winter 2008 Internet Design50 7. Accountability Huge problem. Accounting –Billing? (mostly flat-rate. But phones are moving that way too - people like it!) –Inter-provider payments Hornet’s nest. Complicated. Political. Hard. Accountability and security –Huge problem. –Worms, viruses, etc. Partly a host problem. But hosts very trusted. –Authentication Purely optional. Many philosophical issues of privacy vs. security. –Greedy sources aren’t handled well

52. winter 2008 Internet Design51 Other IP Design Weaknesses Weak administration and management tools Incremental deployment difficult at times –Result of no centralized control –No more “flag” days –Are active networks the solution?

53. winter 2008 Internet Design52 Internet Motto We reject kings, presidents, and voting. We believe in rough consensus and running code.” David Clark

54. winter 2008 Internet Design53 Real Goals 1.Something that works….. 2.Connect existing networks 3.Survivability (not nuclear war…) 4.Support multiple types of services 5.Accommodate a variety of networks 6.Allow distributed management 7.Easy host attachment 8.Cost effective 9.Allow resource accountability

55. winter 2008 Internet Design54 Summary: Internet Architecture Packet-switched datagram network IP is the “compatibility layer” –Hourglass architecture –All hosts and routers run IP Stateless architecture –No per flow state inside network IP TCPUDP ATM Satellite Ethernet

56. winter 2008 Internet Design55 Summary: Minimalist Approach Dumb network –IP provide minimal functionalities to support connectivity Addressing, forwarding, routing Smart end system –Transport layer or application performs more sophisticated functionalities Flow control, error control, congestion control Advantages –Accommodate heterogeneous technologies (Ethernet, modem, satellite, wireless) –Support diverse applications (telnet, ftp, Web, X windows) –Decentralized network administration Beginning to show age –Unclear what the solution will be  probably IPv6

57. winter 2008 Internet Design56 Questions What priority order would a commercial design have? What would a commercially invented Internet look like? What goals are missing from this list? Which goals led to the success of the Internet?

58. winter 2008 Internet Design57 Requirements for Today’s Internet Some key requirements (“-ities”) Availability and reliability –“Always on”, fault-tolerant, fast recovery from failures, … Quality-of-service (QoS) for applications –fast response time, adequate quality for VoIP, IPTV, etc. Scalability –millions or more of users, devices, … Mobility –untethered access, mobile users, devices, … Security (and Privacy?) –protect against malicious attacks, accountability of user actions? Manageability –configure, operate and manage networks –trouble-shooting network problems Flexibility, Extensibility, Evolvability, ……? –ease of new service creation and deployment? –evolvable to meet future needs?