Taj Mahal Agra India T S Eugene Ng

  • Slides: 39
Download presentation
Taj Mahal, Agra, India T. S. Eugene Ng eugeneng at cs. rice. edu Rice

Taj Mahal, Agra, India T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 1

Temple of Heaven, Beijing, China T. S. Eugene Ng eugeneng at cs. rice. edu

Temple of Heaven, Beijing, China T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 2

Opera House, Sydney, Australia T. S. Eugene Ng eugeneng at cs. rice. edu Rice

Opera House, Sydney, Australia T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 3

Parthenon, Athens, Greece T. S. Eugene Ng eugeneng at cs. rice. edu Rice University

Parthenon, Athens, Greece T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 4

Burj al Arab Hotel, Dubai, UAE T. S. Eugene Ng eugeneng at cs. rice.

Burj al Arab Hotel, Dubai, UAE T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 5

Fallingwater, Mill Run, USA T. S. Eugene Ng eugeneng at cs. rice. edu Rice

Fallingwater, Mill Run, USA T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 6

Notre Dame Cathedral, Paris, France T. S. Eugene Ng eugeneng at cs. rice. edu

Notre Dame Cathedral, Paris, France T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 7

Stata Hall, MIT, Cambridge, USA T. S. Eugene Ng eugeneng at cs. rice. edu

Stata Hall, MIT, Cambridge, USA T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 8

COMP/ELEC 429/556 Introduction to Computer Networks Internet architecture Some slides used with permissions from

COMP/ELEC 429/556 Introduction to Computer Networks Internet architecture Some slides used with permissions from Edward W. Knightly, T. S. Eugene Ng, Ion Stoica, Hui Zhang T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 9

Architecture: Organizing Network Functionality • Goals: Functional, flexible, elegant/beautiful • Many kinds of networking

Architecture: Organizing Network Functionality • Goals: Functional, flexible, elegant/beautiful • Many kinds of networking functionality – e. g. , encoding, framing, routing, addressing, reliability, etc. • Many different network styles and technologies – circuit-switched vs packet-switched, etc. – wireless vs wired, electrical vs optical, etc. • Many different applications – dropbox, web, voice, video, etc. • A network has many nodes (routers, switches, hosts) • Network architecture – On which node(s) should each functionality be placed? – How should functionalities on a node be organized? T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 10

Central question: On which node(s) should functionalities be placed? T. S. Eugene Ng eugeneng

Central question: On which node(s) should functionalities be placed? T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 11

Example: Addressing Which node(s) should be able to interpret network addresses in packets? T.

Example: Addressing Which node(s) should be able to interpret network addresses in packets? T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 12

Example: Routing Which node(s) should make routing decisions? T. S. Eugene Ng eugeneng at

Example: Routing Which node(s) should make routing decisions? T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 13

Example: Routing Which node(s) should make routing decisions? T. S. Eugene Ng eugeneng at

Example: Routing Which node(s) should make routing decisions? T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 14

Example: Reliable File Transfer Host A Host B App OS OS • Idea 1:

Example: Reliable File Transfer Host A Host B App OS OS • Idea 1: put reliability function in the network; i. e. make network reliable • Idea 2: put reliability function in the hosts; i. e. implement correctness check at application and retry if failed T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 15

Example (cont’d) • Idea 1 not complete – Bugs can exist in OS code!

Example (cont’d) • Idea 1 not complete – Bugs can exist in OS code! – Data on disk can be corrupted during write – The receiver has to do the check anyway! • Idea 2 is complete – Full functionality can be entirely implemented at application with no need for guaranteed reliability from other components T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 16

Placing Functionality • The most influential paper about placing functionality is “End-to-End Arguments in

Placing Functionality • The most influential paper about placing functionality is “End-to-End Arguments in System Design” by Saltzer, Reed, and Clark T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 17

Basic Observations • There are many levels in a distributed system: application, OS, network,

Basic Observations • There are many levels in a distributed system: application, OS, network, etc. • Some applications have end-to-end performance requirements – reliability, security, etc. • Implementing these in levels below the applications is very hard – every step along the way must be fail-proof – if not fail-proof, application’s implementation complexity is not reduced – increases lower levels’ complexity – imposes delay and overhead on all applications, even if they don’t have such requirements • The applications: – can satisfy the requirement – can’t depend on the lower levels T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 18

Conservative Interpretation of the End-to-End Argument • Don’t implement a function in a low

Conservative Interpretation of the End-to-End Argument • Don’t implement a function in a low level unless it can be completely implemented in that level – Unless you can relieve the burden from applications, then don’t bother T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 19

Radical Interpretation • Don’t implement anything in a low level that can be implemented

Radical Interpretation • Don’t implement anything in a low level that can be implemented correctly by the applications • Make the low level absolutely minimal – ignore performance issues T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 20

Moderate Interpretation • Think twice before implementing functionality in the network • If hosts

Moderate Interpretation • Think twice before implementing functionality in the network • If hosts can implement functionality correctly, implement it at a lower level only as a performance enhancement • But do so only if it does not impose burden on applications that do not require that functionality T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 21

How to Organize Functionalities on Each Node? T. S. Eugene Ng eugeneng at cs.

How to Organize Functionalities on Each Node? T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 22

Software Modularity Break system into modules: • Well-defined interfaces gives flexibility – can change

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 T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 23

Network Modularity Like software modularity, but with a twist: • Implementation distributed (e. g.

Network Modularity Like software modularity, but with a twist: • Implementation distributed (e. g. across routers and hosts) • Must decide both: – how to break system into modules – where modules are implemented T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 24

Layering • Layering is a particular form of modularization • The system is broken

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 may suffer T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 25

A Naïve Architecture Application Transmission Media SMTP SSH Coaxial cable FTP Fiber optic HTTP

A Naïve Architecture Application Transmission Media SMTP SSH Coaxial cable FTP Fiber optic HTTP Packet radio • new application has to interface to all existing media – adding new application requires O(m) work, m = number of media • new media requires all existing applications be modified – adding new media requires O(a) work, a = number of applications • total work in system O(ma) eventually too much work to add apps/media T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 26

Solution: Indirection • Solution: introduce an intermediate layer that provides a single abstraction for

Solution: Indirection • Solution: introduce an intermediate layer that provides a single abstraction for various network technologies – O(1) work to add app/media vs Application SMTP SSH NFS HTTP Intermediate layer Transmission Media T. S. Eugene Ng Coaxial cable Fiber optic eugeneng at cs. rice. edu 802. 11 LAN Rice University 27

Take home point: The Internet Hourglass T. S. Eugene Ng eugeneng at cs. rice.

Take home point: The Internet Hourglass T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 28

Implications of Hourglass A single Internet layer module: • Allows all networks to interoperate

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 T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 29

Internet Protocol Architecture • The TCP/IP protocol suite is the basis for the networks

Internet Protocol Architecture • The TCP/IP protocol suite is the basis for the networks that we call the Internet. • The TCP/IP suite has four layers: Application, Transport, Network, and (Data) Link Layer. Dropbox, Skype, Web Physical Layer T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 30

Terminology • Service – says what a layer does – Ethernet: unreliable subnet unicast/multicast/broadcast

Terminology • Service – says what a layer does – Ethernet: unreliable subnet unicast/multicast/broadcast datagram service – IP: unreliable end-to-end unicast datagram service – TCP: reliable end-to-end bi-directional byte stream service • Service Interface – says how to access the service – E. g. UNIX socket interface • Protocol – says how the service is implemented – a set of rules and formats that govern the communication between two peers T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 31

Physical Layer (1) • Service: move information between two systems connected by a physical

Physical Layer (1) • Service: move information between two systems connected by a physical link • Interface: specifies how to send a bit • Protocol: coding scheme used to represent a bit, voltage levels, duration of a bit • Examples: coaxial cable, optical fiber links T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 32

Datalink Layer (2) • Service: – framing (attach frame separators) – send data frames

Datalink Layer (2) • Service: – framing (attach frame separators) – send data frames between peers – others: • arbitrate the access to common physical media • per-hop reliable transmission • per-hop flow control • Interface: send a data unit (packet) to a machine connected to the same physical media • Protocol: layer addresses, implement Medium Access Control (MAC) (e. g. , IEEE 802. 3, IEEE 802. 11, CSMA/CD)… T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 33

Network Layer (3) • Service: – deliver a packet to specified network destination –

Network Layer (3) • Service: – deliver a packet to specified network destination – perform segmentation/reassemble – others will be discussed • Interface: send a packet to a specified destination • Protocol: define global unique addresses; construct routing tables (e. g IPv 4, IPv 6) T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 34

Transport Layer (4) • Service: – Multiplexing/demultiplexing – optional: error-free and flow-controlled delivery •

Transport Layer (4) • Service: – Multiplexing/demultiplexing – optional: error-free and flow-controlled delivery • Interface: send message to specific destination • Protocol: implements reliability and flow control • Examples: TCP and UDP T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 35

Application Layer (7) • Service: any service provided to the end user • Interface:

Application Layer (7) • Service: any service provided to the end user • Interface: depends on the application • Protocol: depends on the application • Examples: Dropbox, Skype, Web T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 36

Internet Protocol Architecture Web browser TCP IP Ethernet Driver HTTP protocol Web server TCP

Internet Protocol Architecture Web browser TCP IP Ethernet Driver HTTP protocol Web server TCP protocol TCP IP protocol Ethernet protocol T. S. Eugene Ng Ethernet Driver IP IP protocol ATM Driver eugeneng at cs. rice. edu ATM protocol IP ATM Driver Rice University 37

Encapsulation • As data is moving down the protocol stack, each protocol is adding

Encapsulation • As data is moving down the protocol stack, each protocol is adding layer-specific control information. T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 38

Reality • Layering and E 2 E Principle regularly violated: – Firewall – Network

Reality • Layering and E 2 E Principle regularly violated: – Firewall – Network address translation – Transparent web cache • Battle between architectural purity and commercial pressures T. S. Eugene Ng eugeneng at cs. rice. edu Rice University 39