CS542 Internet System Technology WST510 Web Architecture Lecture #2 Sue Moon and Ben Zhao

Today’s Agenda History of the Internet Design goals Layering End-to-end arguments 3

Internet History

1961Kleinrock advocates packet switching (why?) – In parallel, packet switching work done at RAND and NPL 1962Licklider’s vision of Galactic Network 1965Roberts connects 2 computers over phone line 1967Roberts publishes vision of ARPANET 1969BBN installs first 1970Network Control Protocol – assumed reliable transmission! 1972public demonstration of ARPANET 1972 invented 1972Kahn advocates Open Architecture networking 5

The Problem Many different packet-switching networks Only nodes on the same network could communicate 6

Kahn’s Ground Rules Each network is independent and must not be required to change Best-effort communication Boxes (routers) connect networks No global control at operations level 7

Solution 8 Gateways

Question Kahn imagined there would be only a few net works (~20) and thus only a few routers He was wrong Why? 9

Internet Evolution (1960s plan) 10

Internet Evolution

Internet Evolution (April 1971) 12

Internet Evolution (Sept. 1971) 13

Internet Evolution (Sept. 1971) 14

15 “Today (~2000)”

History Continued 1974Cerf and Kahn paper on TCP/IP 1980TCP/IP adopted as defense standard 1983Global NCP to TCP/IP flag day 198xXNS, DECbit, and other protocols 1985NSFnet (picks TCP/IP) 198xInternet meltdowns due to congestion Van Jacobson saves the Internet (BSD TCP) 1988Deering and Cheriton propose multicast, Morris Worm 199xQoS rises and falls 199xATM rises and falls (as an internetworking layer) 1994Internet goes commercial 200xThe Internet boom and bust 16

Internet Design Goals

Goals (Clark’88) Connect existing networks Robust in face of failures (not nuclear war…) Support multiple types of services Accommodate a variety of networks Allow distributed management Easy host attachment Cost effective Allow resource accountability 18

Robust As long as the network is not partitioned, two endpoints sh ould be able to communicate Failures (except network partitions) should not interfere wit h endpoint semantics (why?) Maintain state only at end-points, why? – Fate-sharing State dies IFF endpoint using it dies eliminates network state restoration Protection against a # of failures, easy to engineer – stateless network architecture (no per-flow state) Routing state is held by network (why?) 19

Types of Services Use of the term “communication services” already implied that they wanted application- neutral network Realized TCP wasn’t needed (or wanted) by some applications – Remote debugging, delivery of digitized speech Separated TCP from IP, and introduced UDP – What’s missing from UDP? 20

Variety of Networks Incredibly successful! – Minimal requirements on networks – No need for reliability, in-order, fixed size packets, etc. IP over everything – Then: ARPANET, X.25, DARPA satellite network.. – Now: ATM, SONET, WDM… 21

Host Attachment Clark observes that the cost of host attachmen t may be somewhat higher – Because edge hosts have to be smart But the administrative cost of adding hosts is v ery low, which is probably more important 22

Real Goals Something that works….. Connect existing networks Survivability (not nuclear war…) Support multiple types of services Accommodate a variety of networks Allow distributed management Easy host attachment Cost effective Allow resource accountability 23

Questions What priority order would a commercial design h ave? What would a commercially invented Internet loo k like? What goals are missing from this list? Which goals led to the success of the Internet? 24

Layering and other General Mutterin gs about Internet Architecture

Logical Communication Layers interacts with corresponding layer on p eer 26 Application Presentation Session Transport Network Datalink Physical Application Presentation Session Transport Network Datalink Physical Network Datalink Physical Physical medium Host A Host B Router

OSI vs. Internet OSI: conceptually define services, interfaces, protocols Internet: provide a successful implementation 27 Application Presentation Session Transport Network Datalink Physical Internet Net access/ Physical Transport Application IP LAN Packet radio TCPUDP TelnetFTPDNS OSI (formal) Internet (informal)

Hourglass 28

Implications of Hourglass A single Internet layer module: Allows all networks to interoperate – all networks technologies that support IP can exchang e 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 29

Can We Shift the Hourglass? 30 HTTP as the new IP? HTTP as the new IP?

Endless Arguments about End-to -End

Placing Functionality The most influential paper about placing funct ionality is “End-to-End Arguments in System D esign” by Saltzer, Reed, and Clark The “Sacred Text” of the Internet – endless disputes about what it means – everyone cites it as supporting their position 32

Basic Observation Some applications have end-to-end performance requirements – reliability, security, etc. Implementing these in the network is very hard: – every step along the way must be fail-proof The hosts: – can satisfy the requirement without the network – can’t depend on the network 33

Example: Reliable File Transfer Solution 1: make each step reliable, and then c oncatenate them Solution 2: end-to-end check and retry 34 OS Appl. OS Appl. Host AHost B OK

Example (cont’d) Solution 1 not complete – What happens if any network element misbehaves? – The receiver has to do the check anyway! Solution 2 is complete – Full functionality can be entirely implemented at appli cation layer with no need for reliability from lower lay ers Is there any need to implement reliability at lowe r layers? 35

Example: Speech / VoIP Standard example for E2E argument – Packets need “semi-reliable” delivery at endpoint for t ransformation into audio If lower layers try for “perfect reliability,” – Delay and retransmit at link layer – Result: uncontrolled delays and stream disruption Instead, endpoint can tolerate some data loss – Rely on the ultimate “endpoint,” the human – “What did you just say?” – This is the source of much “cross-layer” work in the m ultimedia networking community 36

Conclusion Implementing this functionality in the network: Doesn’t reduce host implementation complexity Does increase network complexity Probably imposes delay and overhead on all appli cations, even if they don’t need functionality However, implementing in network can enhance performance in some cases – very lossy link 37

What the Paper Says The function in question can completely and corre ctly be implemented only with the knowledge an d help of the application standing at the end poin ts of the communication system. Therefore, provi ding that questioned function as a feature of the communication system itself is not possible. (Som etimes an incomplete version of the function pro vided by the communication system may be usef ul as a performance enhancement.) BTW, E2E also applicable to OS and H/W design… 38

Conservative Interpretation “Don’t implement a function at the lower level s of the system unless it can be completely im plemented at this level” (Peterson and Davie) Unless you can relieve the burden from hosts, then don’t bother 39

Radical Interpretations Don’t implement anything in the network that ca n be implemented correctly by the hosts – e.g., multicast – Makes network layer absolutely minimal – Ignores performance issues Don’t rely on anything that’s not on the data path – E.g., no DNS – Makes network layer more complicated 40

Moderate Interpretation Think twice before implementing functionality in the network If hosts can implement functionality correctly, im plement it a lower layer only as a performance en hancement But do so only if it does not impose burden on ap plications that do not require that functionality 41

Do These Belong in the Network? Multicast? Routing? Quality of Service (QoS)? Name resolution? (is DNS “in the network”?) Web caches? 42