Network Architecture. EE 122, Fall 2013 Sylvia Ratnasamy

Transcription

1 Network Architecture EE 122, Fall 2013 Sylvia Ratnasamy

2 Administrivia l Enrollment l l Discussion sections are *not* the bottleneck to enrollment State of the waitlist (as of 09/10): 3 seniors, after which WL will be processed in chronological order l Instructional account forms l l If you are registered for the class and have not received an with your account information, apanda@cs and sylvia@cs If you are on the waitlist and eventually make it into the class, don t worry, we will you an instr. account well in time for you to submit your 1 st HW l drop deadline is 9/27, 1 st HW is due on 10/2

3 Outline Last time: low-level plumbing Today: top-down architecting of the Internet l Goals l Layering l Protocols l The end-to-end principle

4 Recall From Lecture#1 l Architecture is not the implementation itself l Architecture is how we structure implementations l what functions?, where?, what interfaces? l Architecture is the modular design of the network

5 How would you go about designing the Internet? Sit down and l List your goals l Prioritize them l Hence define the service you will offer l Architect a solution that implements the service Of course, the original designers of the Internet didn t do anything of the sort

6 Reality l The lessons accrued over time; many contributors l 1961: packet switching (Baran and Kleinrock) l 1967: vision of a robust network (ARPANET) l 1972: best effort inter-networking proposed (Kahn) l 1974: TCP/IP paper (Cerf/Kahn)

7 Reality l The lessons accrued over time; many contributors l Many of the lessons were learnt on the job l E.g., TCP s congestion control algorithms were developed in response to the Internet meltdowns of the early 1980s

8 Reality l The lessons accrued over time; many contributors l Many of the lessons were learnt on the job l Consensus didn t come easy l 1961: packet switching is proposed l 1972: best-effort communication is advocated l 1980: IP adopted as the defense standard l 1985: NSFnet picks IP l 199x: Circuit switching rises (and falls) in the form of ATM l 199x: `Quality of Service (QoS) rises and falls

9 Reality l The lessons accrued over time; many contributors l Many of the lessons were learnt on the job l Consensus didn t come easy l And progress was ad-hoc l rough consensus and running code.

10 Reality l The lessons accrued over time; many contributors l Many of the lessons were learnt on the job l Consensus didn t come easy l And progress was ad-hoc l Yet, there was also l constant dialogue l constant introspection l constant experimentation, leading to l A strong consistency of vision emerging by the 80s, driven by D. Clark, chair of the Internet Arch. Board

11 Internet Design Goals (from Clark s SIGCOMM 1988 paper)" l Connect existing networks l Robust in face of failures l Support multiple types of delivery services l Accommodate a variety of networks l Allow distributed management l Cost effective l Easy host attachment l Allow resource accountability

12 Connect Existing Networks l Wanted a single unifying interface that could be used to connect any pair of (existing) networks l Interface to be compatible with existing networks l couldn t demand performance capabilities not supported by existing networks l had to support existing packet switched networks l Led to focus on an inter-networking service based on the best-effort delivery of packets

13 How would you go about designing the Internet? Sit down and l List your goals l Prioritize them l Hence define the service you will offer l Architect a solution that implements the service

14 Three steps l Decompose the problem into tasks l Organize these tasks l Assign tasks to entities (who does what)

15 Decomposition What does it take to send packets across the globe? l Bits on wire l Packets on wire Physical l Delivery packets within a single physical network l Deliver packets across multiple networks Datalink Network l Ensure the destination received the data l Do something with the data Application Transport This is decomposition Now, how do we organize these tasks?

16 Inspiration l CEO A writes letter to CEO B l Folds letter and hands it to administrative aide Dear John, l Aide: l Puts letter in envelope with CEO B s full name Your days are numbered. l Takes to FedEx l FedEx Office --Pat l Puts letter in larger envelope l Puts name and street address on FedEx envelope l Puts package on FedEx delivery truck l FedEx delivers to other company

17 The Path of the Letter Peers on each side understand the same things No one else needs to Lowest level has most packaging CEO Semantic Letter Content CEO Aide Envelope Identity Aide FedEx Fedex Location Envelope (FE) FedEx

18 The Path Through FedEx Truck FE Sorting Office Airport Crate Crate FE Sorting Office Airport New Crate FE Crate Truck Sorting Office Airport Deepest Packaging (Envelope+FE+Crate) at the Lowest Level of Transport

19 The Path Through FedEx Higher Stack at Ends Partial Stack Truck During Transit FE Sorting Office Airport Crate Highest Level of Transit Stack is Routing Crate FE Sorting Office Airport New Crate FE Crate Truck Sorting Office Airport Deepest Packaging (Envelope+FE+Crate) at the Lowest Level of Transport

20 In the context of the Internet Applications built on Reliable (or unreliable) transport built on Best-effort global packet delivery built on Best-effort local packet delivery built on Physical transfer of bits This is not nope, a typo not a typo L7 L4 L3 L2 L1 Application Transport Network Data link Physical

21 In the context of the Internet The Open Systems Interconnect (OSI) model developed by the ISO included two additional layers that are often implemented as part of the application Application Presentation Session Transport Network Data link Physical

22 Protocols and Layers L7 Application Application L7 L4 Transport Transport L4 L3 Network Network L3 L2 Data link Data link L2 L1 Physical Physical L1 Communication between peer layers on different systems is defined by protocols

23 What is a Protocol? Friendly greeting Friendly greeting Time? 2pm Thank you

24 What is a Protocol? l E.g., the destination address is in the 1 st four bytes of the packet l When A sends B a packet of type X B should return a packet of type Y to A then A should respond with Z.

25 What is a Protocol? l An agreement between parties on how to communicate l Include syntax and semantics l how a communication is specified and structured l what a communication means l Protocols exist at many hardware, software, all levels! l Defined by a variety of standards bodies l IETF (ietf.org), IEEE, ITU,

26 So we have decomposition and organization L7 Application Application L7 L4 Transport Transport L4 L3 Network Network L3 L2 Data link Data link L2 L1 Physical Physical L1 Next: what gets implemented where?

27 Distributing Layers Across Network l Layers are simple if only on a single machine l Just stack of modules interacting with those above/ below l But we need to implement layers across machines l Hosts l Routers (switches) l What gets implemented where?

28 What gets implemented at the end host? l Bits arrive on wire, must make it up to application l Therefore, all layers must exist at host! 28

29 What gets implemented in l Bits arrive on wire the network? l Physical layer necessary l Packets must be delivered to next-hop and across local networks l Datalink layer necessary l Packets must be delivered between networks for global delivery l Network layer necessary l The network doesn t support reliable delivery 29 l Transport layer (and above) not supported

30 Switches vs. Routers l Switches do what routers do, except they don t participate in global delivery, just local delivery l Switches only need to support Physical and Datalink l Don t need to support Network layer l Routers support Physical, Datalink and Network layers l Won t focus on the router/switch distinction l When I say switch, I almost always mean router l Almost all boxes support network layer these days

31 Simple Diagram" l Lower three layers implemented everywhere l Top two layers implemented only at hosts Application Transport Network Datalink Physical Host A Network Datalink Physical Router Application Transport Network Datalink Physical Host B

32 Looking a little closer At the end host l Application l user space: web server, browser, mail, game l Transport and network. l Typically part of the operating system l Datalink Application Transport Network Data link Physical l Often written by vendor of the network interface hardware l Physical l Hardware: network interface card and link

33 Logical Communication" l Layers interacts with peer s corresponding layer Application Transport Network Datalink Physical Host A Network Datalink Physical Router Application Transport Network Datalink Physical Host B 33

34 Physical Communication" l Communication goes down to physical network l Then from network peer to peer l Then up to relevant layer Application Transport Network Datalink Physical Host A Network Datalink Physical Router Application Transport Network Datalink Physical Host B 34

35 Layer Encapsulation" User A User B Appl: Get index.html Trans: Connection ID Net: Source/Dest Link: Src/Dest

36 Protocols at different layers L7 Application SMTP HTTP DNS NTP L4 Transport TCP UDP L3 Network IP L2 Data link Ethernet FDDI PPP L1 Physical optical copper radio PSTN There is just one network-layer protocol, IP The narrow waist of the Internet hourglass

37 Implications of Hourglass Single network-layer protocol (IP) l Allows arbitrary networks to interoperate l Any network that supports IP can exchange packets l Decouples applications from low-level networking technologies l applications to function on all networks l Supports simultaneous innovations above and below IP l But changing IP itself is hard (e.g., IPv4 à IPv6)

38 A Protocol-Centric Diagram" host host HTTP HTTP message HTTP TCP TCP segment TCP router router IP IP packet IP IP packet IP IP packet IP Ethernet interface Ethernet interface SONET interface SONET interface Ethernet interface Ethernet interface

39 What are some of the benefits of protocols and layering?

40 Interoperability l Many implementations of many technologies l Hosts running FreeBSD, Linux, Windows, MacOS, l People using Mozilla, Explorer, Opera, l Routers made by cisco, juniper, l Hardware made by IBM, Dell, Apple, l And it changes all the time. l Phew! But they can all talk together because they use the same protocol(s)

41 Abstraction & Reuse l Multiple choices of protocol at many layers l Physical: copper, fiber, air, carrier pigeon l Link: ethernet, token ring, SONET, FDDI l Transport: TCP, UDP, SCTP l But we don t want to have to write a web (HTTP) browser for TCP networks running IP over Ethernet on Copper and another for the fiber version l Protocols provide a standard interface to write to l Layers hide the details of the protocols below

42 Decoupling aids innovation l Technologies at each layer pursued by very different communities l Innovation at each layer can proceed in parallel

43 What are some of the drawbacks of protocols and layering?

44 Drawbacks of Layering l Layer N may duplicate lower layer functionality l e.g., error recovery to retransmit lost data l Information hiding may hurt performance l e.g., packet loss due to corruption vs. congestion l Headers start to get really big l e.g., typical TCP+IP+Ethernet is 54 bytes l Layer violations when the gains too great to resist l e.g., TCP-over-wireless l Layer violations when network doesn t trust ends l e.g., firewalls

45 Placing Network Functionality" l Hugely influential paper: End-to-End Arguments in System Design by Saltzer, Reed, and Clark ( 84) l articulated the End-to-End Principle (E2E) l Endless debate over what it means l Everyone cites it as supporting their position

46 Basic Observation" l Some application requirements can only be correctly implemented end-to-end l reliability, security, etc. l Implementing these in the network is hard l every step along the way must be fail proof l Hosts l l Can satisfy the requirement without network s help Will/must do so, since they can t rely on the network

47 Example: Reliable File Transfer" Host A Host B Appl. Appl. OS OK OS l Solution 1: make each step reliable, and string them together to make reliable end-to-end process l Solution 2: end-to-end check and retry

48 Discussion" l Solution 1 is incomplete l l What happens if any network element misbehaves? Receiver has to do the check anyway! l Solution 2 is complete l Full functionality can be entirely implemented at application layer with no need for reliability from lower layers l Is there any need to implement reliability at lower layers?

49 Summary of End-to-End Principle " l Implementing functionality (e.g., reliability) in the network l l l Doesn t reduce host implementation complexity Does increase network complexity Probably increases delay and overhead on all applications even if they don t need the functionality (e.g. VoIP) l However, implementing in the network can improve performance in some cases l e.g., consider a very lossy link

50 Only-if-Sufficient Interpretation" l Don t implement a function at the lower levels of the system unless it can be completely implemented at this level l Unless you can relieve the burden from hosts, don t bother

51 Only-if-Necessary Interpretation" l Don t implement anything in the network that can be implemented correctly by the hosts l Make network layer absolutely minimal l This E2E interpretation trumps performance issues l Increases flexibility, since lower layers stay simple

52 Only-if-Useful Interpretation" l If hosts can implement functionality correctly, implement it in a lower layer only as a performance enhancement l But do so only if it does not impose burden on applications that do not require that functionality

53 Taking stock of where we re at "

54 First Step: Basic Concepts and Decisions l Plumbing: links, switches l Packet Switching winner over circuit switching l Best-effort service model

55 Second Step: Architectural Principles l Protocols and Layering l End-to-End Principle

56 Third Step: Design Challenges and Solutions l Let s go layer by layer l Physical l Datalink l Network l Transport l Application

57 Two Layers We ll Worry About Less l Physical: l Technology dependent l Lots of possible solutions l Not specific to the Internet l Application: l Application-dependent l Lots of possible solutions

58 Datalink and Network Layers l Both support best-effort delivery l Datalink over local scope l Network over global scope l Key challenge: scalable, robust routing l How do we address destinations l How to direct packets to destination

59 Transport Layer l Provide reliable delivery over unreliable network

60 Hence, Course Roadmap l Routing and the IP network layer l next 4-5 lectures + project 1 l Reliable delivery and the TCP transport layer l lectures up to the midterm + project 2 l Lectures in the 2 nd half of the course will fill in the rest of the picture l Ethernet, HTTP, security, new directions, etc.