Internet Design: Big Picture

Transcription

1 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, 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 1 2 Architectural Principles (not unique to networks!) End-to-end argument functionality placement Modularity Increase inter-operability and manage complexity layered architecture 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, Some Design/Implementation Principles virtualization indirection soft state vs. hard state fate sharing randomization expose faults caching 3 4

2 Original Internet Design Goals [Clark 88] In order of importance: 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 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 Connecting Existing Networks Cerf & Kahn: Interconnecting Two 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? ARPAnet satellite net 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. 7 8

3 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! Translation Gateway Alternative 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 9 10 Design of Original Internet via Gateways Internetwork layer: addressing: internetwork appears as a single, uniform entity, despite underlying local network heterogeneity network of networks (cf. Cerf and Kahn) Gateway: embed internetwork packets in local packet format or extract them route (at internetwork level) to next gateway Historical Aside: Proposed Internetwork packet in 1974: local header source dest. address address seq. # byte count flag field text checksum network TCP identifier gateway 8 16 ARPAnet satellite net 11 12

4 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 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?) 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? Connection State Fate Sharing Lose state information for an entity if (and only if?) the entity itself is lost. Examples: No State State 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 15 16

5 Basic behavior Announce state Refresh state Timeout state Soft-State Penalty for timeout poor performance Robust way to identify communication flows Possible mechanism to provide non-best effort service Helps survivability 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 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 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! 19 20

6 Do These Belong in the Network? 2. Types of Service Multicast? Routing? Quality of Service (QoS)? Name resolution? (is DNS in the network?) Web caches? 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 Types of Service (cont d) 3. Varieties of Networks TCP vs. UDP Elastic apps that need reliability: remote login or 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 voice, etc. These differences caused the layer split, added UDP 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 23 24

7 The Other goals 7. Accountability 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 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 Other IP Design Weaknesses Internet Motto Weak administration and management tools Incremental deployment difficult at times Result of no centralized control No more flag days Are active networks the solution? We reject kings, presidents, and voting. We believe in rough consensus and running code. David Clark 27 28

8 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 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 TCP IP Ethernet UDP Satellite ATM 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? 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? 31 32

9 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? 33