The Internet
description
Transcript of The Internet
winter 2008 Internet Design 1
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 )– Technical basis for other types of networks
• Intranet: enterprise IP network• Developed by the research community
winter 2008 Internet Design 2
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, …
winter 2008 Internet Design 3
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
winter 2008 Internet Design 6
Growth of the Internet• Number of Hosts
on the Internet:Aug. 1981 213Oct. 1984 1,024Dec. 1987 28,174 Oct. 1990 313,000 Oct. 1993 2,056,000Apr. 1995 5,706,000Jan. 1997 16,146,000Jan. 1999 56,218,000Jan. 2001 109,374,000Jan. 2003 171,638,297Jul 2004 285,139,107Jul 2005 353,284,187
winter 2008 Internet Design 7
Today’s Internet
LANs
International lines
ISP ISPcompany university
national network
regionalnetwork
NAPInternic
on-line services
companyaccess via
modem
Internet: “networks of networks” at global scale!
3G cellular networks
WiFi
winter 2008 Internet Design 14
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 ISP
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
winter 2008 Internet Design 15
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
Tier 1 ISP
Tier 1 ISP
IXP
Tier-2 ISPTier-2 ISP
Tier-2 ISP Tier-2 ISPTier-2 ISP
Tier-2 ISP pays tier-1 ISP for connectivity to rest of Internet tier-2 ISP is customer oftier-1 provider
Tier-2 ISPs also peer privately with each other, interconnect at IXPs
winter 2008 Internet Design 16
Internet Structure: Network of Networks• “Tier-3” ISPs and local ISPs
– last hop (“access”) network (closest to end systems)
Tier 1 ISP
Tier 1 ISP
Tier 1 ISP
NAP
Tier-2 ISPTier-2 ISP
Tier-2 ISP Tier-2 ISPTier-2 ISP
localISPlocal
ISPlocalISP
localISP
localISP Tier 3
ISP
localISP
localISP
localISP
Local and tier- 3 ISPs are customers ofhigher tier ISPsconnecting them to rest of Internet
winter 2008 Internet Design 17
Internet Structure: Network of Networks• a packet passes through many networks!
Tier 1 ISP
Tier 1 ISP
Tier 1 ISP
NAP
Tier-2 ISPTier-2 ISP
Tier-2 ISP Tier-2 ISPTier-2 ISP
localISPlocal
ISPlocalISP
localISP
localISP Tier 3
ISP
localISP
localISP
localISP
Try atraceroute!
host/network edge: IP addresses, port no’s network core: intra-domain vs. inter-domain routing
winter 2008 Internet Design 18
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, …;
winter 2008 Internet Design 19
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)
winter 2008 Internet Design 20
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 addressesMany responsibilities (e.g., those of IANA) are now
taken over by the Internet Corporation for Assigned Names and Numbers (ICANN)
winter 2008 Internet Design 21
Internet Hourglass Architecture
winter 2008 Internet Design 22
Implications of HourglassA 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
winter 2008 Internet Design 23
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
winter 2008 Internet Design 24
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.”
winter 2008 Internet Design 26
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, …
winter 2008 Internet Design 27
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
winter 2008 Internet Design 28
Some Design/Implementation Principles
• virtualization• indirection• soft state vs. hard state• fate sharing• randomization• expose faults, don’t suppress/ignore• caching• ……
winter 2008 Internet Design 29
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 services3. Must accommodate a variety of networks4. Allow distributed management5. Allow host attachment with a low level of effort6. Be cost effective7. Allow resource accountability
In order of importance:
winter 2008 Internet Design 30
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
winter 2008 Internet Design 31
0. Connecting Existing Networks1974: 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?
winter 2008 Internet Design 32
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
winter 2008 Internet Design 33
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!
winter 2008 Internet Design 34
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
winter 2008 Internet Design 35
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
winter 2008 Internet Design 36
Historical Aside: Proposed Internetwork packet in 1974:
localheader
sourceaddress
dest.address seq. # byte
countflagfield text checksum
network TCPidentifier
8 16
winter 2008 Internet Design 37
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
winter 2008 Internet Design 38
1. Survivability1. As long as the network is not partitioned, two
endpoints should be able to communicate2. 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?)
winter 2008 Internet Design 39
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?
Network Host
Failure handing Replication “Fate sharing”
Switches Maintain state Stateless
Host trust Less More
winter 2008 Internet Design 40
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 StateNo State
winter 2008 Internet Design 41
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
winter 2008 Internet Design 42
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
winter 2008 Internet Design 43
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
winter 2008 Internet Design 44
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!
winter 2008 Internet Design 45
Do These Belong in the Network?
• Multicast?• Routing?• Quality of Service (QoS)?• Name resolution? (is DNS “in the
network”?)• Web caches?
winter 2008 Internet Design 46
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…
winter 2008 Internet Design 47
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
winter 2008 Internet Design 48
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
winter 2008 Internet Design 49
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…
winter 2008 Internet Design 50
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
winter 2008 Internet Design 51
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?
winter 2008 Internet Design 52
Internet MottoWe reject kings , presidents, and voting.
We believe in rough consensus and running code.”
David Clark
winter 2008 Internet Design 53
Real Goals1. Something that works…..2. Connect existing networks3. Survivability (not nuclear war…)4. Support multiple types of services5. Accommodate a variety of networks6. Allow distributed management7. Easy host attachment8. Cost effective9. Allow resource accountability
winter 2008 Internet Design 54
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
TCP UDP
ATM
Satellite
Ethernet
winter 2008 Internet Design 55
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
winter 2008 Internet Design 56
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?
winter 2008 Internet Design 57
Requirements for Today’s InternetSome 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?