CS 268: Lecture 3.

Slides:



Advertisements
Similar presentations
T. S. Eugene Ngeugeneng at cs.rice.edu Rice University1 COMP/ELEC 429 Introduction to Computer Networks Internet architecture Slides used with permissions.
Advertisements

Layering and the network layer CS168, Fall 2014 Sylvia Ratnasamy
COS 461 Fall 1997 Networks and Protocols u networks and protocols –definitions –motivation –history u protocol hierarchy –reasons for layering –quick tour.
Data and Computer Communications Eighth Edition by William Stallings Lecture slides by Lawrie Brown Chapter 2 – Protocol Architecture, TCP/IP, and Internet-Based.
PROTOCOLS AND ARCHITECTURE Lesson 2 NETS2150/2850.
1 Katz, Stoica F04 EECS 122: Introduction to Computer Networks Network Architecture Computer Science Division Department of Electrical Engineering and.
Protocols and the TCP/IP Suite Chapter 4 (Stallings Book)
CS 268: Lecture 2 (Layering & End-to-End Arguments)
Semester Copyright USM EEE442 Computer Networks Introduction: Protocols En. Mohd Nazri Mahmud MPhil (Cambridge, UK) BEng (Essex, UK)
EE 122: Layering and the Internet Architecture Kevin Lai September 4, 2002.
Chapter 1 Read (again) chapter 1.
COE 342: Data & Computer Communications (T042) Dr. Marwan Abu-Amara Chapter 2: Protocols and Architecture.
Plan of attack ‣ What is a network made of? ‣ How is it shared? ‣ How do we evaluate a network? ‣ How is communication organized? 1.
CS 268: Lecture 4 (Internet Architecture & E2E Arguments)
Computer Networking Lent Term M/W/F 11-midday LT1 in Gates Building Slide Set 2 Andrew W. Moore January
EPL606 Topic 1 Introduction Part B - Design Considerations 1 The majority of the slides in this course are adapted from the accompanying slides to the.
CS 268: Lecture 3 (Layering & End-to-End Arguments)
Review: – computer networks – topology: pair-wise connection, point-to-point networks and broadcast networks – switching techniques packet switching and.
What is a Protocol A set of definitions and rules defining the method by which data is transferred between two or more entities or systems. The key elements.
T. S. Eugene Ngeugeneng at cs.rice.edu Rice University1 Taj Mahal, Agra, India.
CS542 Internet System Technology WST510 Web Architecture Lecture #2 Sue Moon and Ben Zhao.
T. S. Eugene Ngeugeneng at cs.rice.edu Rice University1 COMP/ELEC 429 Introduction to Computer Networks Lecture 5: Internet architecture Slides used with.
Department of Electronic Engineering City University of Hong Kong EE3900 Computer Networks Introduction Slide 1 A Communications Model Source: generates.
Internet Security - Farkas1 CSCE 813 Internet Security TCP/IP.
CS 268: Internet Architecture & E2E Arguments Scott Shenker and Ion Stoica (Fall, 2010) 1.
TCOM 509 – Internet Protocols (TCP/IP) Lecture 03_b Protocol Layering Instructor: Dr. Li-Chuan Chen Date: 09/15/2003 Based in part upon slides of Prof.
TCP/IP Network.
William Stallings Data and Computer Communications
CS 4700 / CS 5700 Network Fundamentals
CS 3700 Networks and Distributed Systems
CS 4700 / CS 5700 Network Fundamentals Lecture 3: Internet Architecture (Layer cake and an hourglass) Revised 1/11/16.
Data and Computer Communications Chapter 2 – Protocol Architecture, TCP/IP, and Internet-Based Applications.
OSI Model OSI MODEL. Communication Architecture Strategy for connecting host computers and other communicating equipment. Defines necessary elements for.
OSI Model OSI MODEL.
CS 4700 / CS 5700 Network Fundamentals
CS 3700 Networks and Distributed Systems
What is a Protocol A set of definitions and rules defining the method by which data is transferred between two or more entities or systems. The key elements.
Networking Using the OSI Model.
Protocols and the TCP/IP Suite
Lecture (2).
E2E Arguments & Project Suggestions (Lecture 4, cs262a)
March 14, 2011 Ion Stoica CS162 Operating Systems and Systems Programming Lecture 14 Protocols, Layering and e2e.
OSI Protocol Stack Given the post man exemple.
Lecturer, Department of Computer Application
CS 268: Computer Networking
Lecture 6: TCP/IP Networking By: Adal Alashban
Network Architecture Introductory material
CS 4700 / CS 5700 Network Fundamentals
Net 431: ADVANCED COMPUTER NETWORKS
Taj Mahal, Agra, India T. S. Eugene Ng eugeneng at cs.rice.edu Rice University.
Administrative stuff TA: Almudena Konrad Paper reviews:
CPE 401 / 601 Computer Network Systems
Protocols and the TCP/IP Suite
CS 3700 Networks and Distributed Systems
Data and Computer Communications by William Stallings Eighth Edition
Review of Important Networking Concepts
CS 268: Lecture 4 (TCP/IP Architecture)
E2E Arguments & Project Suggestions (Lecture 4, cs262a)
EEL 5718 Computer Communications
Lecture 6: TCP/IP Networking 1nd semester By: Adal ALashban.
1 TRANSMISSION CONTROL PROTOCOL / INTERNET PROTOCOL (TCP/IP) K. PALANIVEL Systems Analyst, Computer Centre Pondicherry University, Puducherry –
OSI Model OSI MODEL.
Internet Architecture: Design Philosophy -Then and Now
EE122: Potpourri November 24, 2003.
Protocols and the TCP/IP Suite
EEC4113 Data Communication & Multimedia System Chapter 1: Introduction by Muhazam Mustapha, July 2010.
November 26th, 2018 Prof. Ion Stoica
Network Basics and Architectures Neil Tang 09/05/2008
Presentation transcript:

CS 268: Lecture 3

Four Additional 268 Projects Build a sensornet DHT without node addresses or point-to-point routing OpenDHT support for online communities (OpenDHT) letter of recommendation processing Cheap AS-level spoof-protection

268 Projects Did anyone understand what we said last time? Talk to us, other students, strangers on the street…

Today’s Agenda Course overview History of the Internet Design goals Layering (review) End-to-end arguments (review)

Course Theme Focus on the Internet Other topics covered, but Internet is main focus Will study the current Internet design and reality But will also discuss possible design alternatives

Topics General Internet background (review) TCP/IP (historical) TCP congestion control Beyond TCP Router Support for congestion control Intradomain routing Interdomain routing Multicast routing QoS: Intserv and DiffServ Mobility

Topics Continued Security: crypto Security: robust protocols Security: malware Web Overlay networks P2P-style overlays Distributed Computing Wireless Sensornets (2) Perspectives on Internet Architecture Alternatives to the Internet Architecture (2)

Internet History

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

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

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

Solution Gateways

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

History Continued 1974 Cerf and Kahn paper on TCP/IP 1980 TCP/IP adopted as defense standard 1983 Global NCP to TCP/IP flag day 198x XNS, DECbit, and other protocols 1984 Janet 1985 NSFnet (picks TCP/IP) 198x Internet meltdowns due to congestion 1986+ Van Jacobson saves the Internet (BSD TCP) 1988 Deering and Cheriton propose multicast 199x QoS rises and falls 199x ATM rises and falls (as an internetworking layer) 1994 Internet goes commercial 200x The Internet boom and bust 2001 Ion Stoica gets Ph. D.!

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

Robust As long as the network is not partitioned, two endpoints should be able to communicate 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?)

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 Separated TCP from IP, and introduced UDP What’s missing from UDP?

Variety of Networks Incredibly successful! IP over everything 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…

Host Attachment Clark observes that the cost of host attachment may be somewhat higher because hosts have to be smart But the administrative cost of adding hosts is very low, which is probably more important

Why Datagrams? No connection state needed Good building block for variety of services Minimal network assumptions

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

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

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? Missing: resource sharing, other considerations of malicious users (traceback, etc.), address concerns of administrative domains visible

Layering and other General Mutterings about Internet Architecture Repeats122 material

The Big Question Many different network styles and technologies circuit-switched vs packet-switched, etc. wireless vs wired vs optical, etc. Many different applications ftp, email, web, P2P, etc. How do we organize this mess?

The Problem Do we re-implement every application for every technology? HTTP Application Telnet FTP NFS Coaxial cable Fiber optic Packet radio Transmission Media Do we re-implement every application for every technology? Obviously not, but how does the Internet architecture avoid this?

Architecture Architecture is not the implementation itself Architecture is how to “organize” implementations what interfaces are supported where functionality is implemented Architecture is the modular design of the network

Software Modularity Break system into modules: Well-defined interfaces gives flexibility can change implementation of modules can extend functionality of system by adding new modules Interfaces hide information allows for flexibility but can hurt performance

Network Modularity Like software modularity, but with a twist: Implementation distributed across routers and hosts Must decide both: how to break system into modules where modules are implemented Lecture will address these questions in turn

Two Aspects to Architecture Layering how to break network functionality into modules The End-to-End Argument where to implement functionality

Layering Layering is a particular form of modularization The system is broken into a vertical hierarchy of logically distinct entities (layers) The service provided by one layer is based solely on the service provided by layer below Rigid structure: easy reuse, performance suffers

ISO OSI Reference Model for Layers Application Presentation Session Transport Network Datalink Physical

Where Do These Fit? IP TCP Email Ethernet

Layering Solves Problem Application layer doesn’t know about anything below the presentation layer, etc. Information about network is hidden from higher layers This ensures that we only need to implement an application once!

OSI Model Concepts Service: what a layer does Service interface: how to access the service interface for layer above Peer interface (protocol): how peers communicate a set of rules and formats that govern the communication between two network boxes protocol does not govern the implementation on a single machine, but how the layer is implemented between machines

Who Does What? Seven layers Lower three layers are implemented everywhere Next four layers are implemented only at hosts Host A Host B Application Application Presentation Presentation Session Session Transport Router Transport Network Network Network Datalink Datalink Datalink Physical Physical Physical Physical medium

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

Physical Communication Communication goes down to physical network, then to peer, then up to relevant layer Host A Host B Application Application Presentation Presentation Session Session Transport Router Transport Network Network Network Datalink Datalink Datalink Physical Physical Physical Physical medium

Encapsulation A layer can use only the service provided by the layer immediate below it Each layer may change and add a header to data packet data data data data data data data data data data data data data data

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

Hourglass

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

Back to Reality Layering is a convenient way to think about networks But layering is often violated Firewalls Transparent caches NAT boxes ....... What problems does this cause? What is an alternative to layers?

Endless Arguments about End-to-End

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

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

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

Example (cont’d) Solution 1 not complete Solution 2 is 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 application layer with no need for reliability from lower layers Is there any need to implement reliability at lower layers?

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

What the Paper Says The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)

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

Radical Interpretations Don’t implement anything in the network that can 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

Moderate Interpretation Think twice before implementing functionality in the network If hosts can implement functionality correctly, implement it a lower layer only as a performance enhancement But do so only if it does not impose burden on applications that do not require that functionality

Extended Version of E2E Argument Don’t put application semantics in network Leads to loss of flexibility Cannot change old applications easily Cannot introduce new applications easily Normal E2E argument: performance issue introducing more functionality imposes more overhead subtle issue, many tough calls (e.g., multicast) Extended version: short-term performance vs long-term flexibility

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

Back to Reality (again) Layering and E2E Principle regularly violated: Firewalls Transparent caches Other middleboxes Battle between architectural purity and commercial pressures extremely important imagine a world where new apps couldn’t emerge

Challenge Install functions in network that aid application performance…. …without limiting the application flexibility of the network

Next Time We will design IP from scratch…..