Download presentation
Presentation is loading. Please wait.
Published byAdele Smith Modified over 8 years ago
1
Introduction to Communication Networks – 67594 Dr. Michael Schapira Rothberg A413 schapiram@huji.ac.il Some of the slides were taken from Prof. Scott Shenker, UC Berkeley
2
2 Communication networks can be classified based on the way in which the nodes exchange information: Taxonomy of Communication Networks Communication Network
3
3 Communication networks can be classified based on the way in which the nodes exchange information: Taxonomy of Communication Networks Communication Network Broadcast Communication Network
4
4 Information transmitted by any node is received by every other node in the network –Usually only in LANs (Local Area Networks) E.g., WiFi, Ethernet (classical, but not current) E.g., lecture! What problems does this raise? Problem #1: limited range Problem #2: coordinating access to the shared communication medium –Multiple Access Problem Problem #3: privacy of communication Broadcast Communication Networks
5
5 Communication networks can be classified based on the way in which the nodes exchange information: Taxonomy of Communication Networks Communication Network Switched Communication Network Broadcast Communication Network
6
6 Communication networks can be classified based on the way in which the nodes exchange information: Taxonomy of Communication Networks Communication Network Switched Communication Network Broadcast Communication Network Circuit-Switched Communication Network
7
7 Communication networks can be classified based on the way in which the nodes exchange information: Taxonomy of Communication Networks Communication Network Switched Communication Network Broadcast Communication Network Circuit-Switched Communication Network Packet-Switched Communication Network (Datagram Network)
8
Packets / Datagrams Payload (Body) – Data being transferred Header – Instructions to the network for how to handle packet 8 Payload Header
9
9 Datagram Packet Switching Each packet is independently switched –Each packet header contains full destination address No resources are pre-allocated (reserved) in advance
10
Bursts Packets arrive at the nodes in different patterns: – Bursty/smooth sources – Multiplexing different flows creates bursts time
11
Buffers to mitigate bursts Due to bursts, sometime transient arrival rate is larger than transmission rate – Even if long-term arrival rate is smaller than transmission rate One possibility: drop packets Better approach: add buffers to save excess packets (until the bursts ends) – Even when buffers, sometimes packets are lost – Even with infinite buffers, sometimes packets are lost
12
Data Rate 1 Data Rate 2 Data Rate 3 Three Flows with Bursty Arrivals Time Capacity
13
Data Rate 1 Data Rate 2 Data Rate 3 When Each Flow Gets 1/3 rd of Capacity Time Frequent Overloading
14
When Flows Share Total Capacity Time No Overloading Statistical multiplexing relies on the assumption that not all flows burst at the same time. Very similar to insurance, and has same failure case
15
So, if you were building a network…. Which would you choose? – Circuit switched? – Packet-switched? Let’s review the strengths and weaknesses 15
16
16 Advantages of Circuit Switching Guaranteed bandwidth –Predictable communication performance –Not “best-effort” delivery with no real guarantees Simple abstraction –Reliable communication channel between hosts –No worries about lost or out-of-order packets Simple forwarding –Forwarding based on time slot or frequency –No need to inspect a packet header Low per-packet overhead –Forwarding based on time slot or frequency –No headers on each packet
17
17 Disadvantages of Circuit Switching Wasted bandwidth –Bursty traffic leads to idle connection during silent period –Unable to achieve gains from “statistical multiplexing” Blocked connections –Connection refused when resources are not sufficient –Unable to offer “okay” service to everybody Network state –Network nodes must store per-connection information –Unable to avoid per-connection storage and state –This makes failures more disruptive! Connection set-up delay –No communication until the connection is set up –Unable to avoid extra latency for small data transfers
18
Packet-Switching vs. Circuit-Switching Reliability advantage: since routers don’t know about individual conversations, when a router or link fails, it is easy to fail over to a different path Efficiency advantage of packet-switching over circuit switching: Exploitation of statistical multiplexing Deployability advantage: easier for different parties to link their networks together because they’re not promising to reserve resources for one another Disadvantage: packet-switching must handle congestion –More complex routers (more buffering, sophisticated dropping) –Harder to provide good network services (e.g., delay and bandwidth guarantees) 18
19
Internet Design Principles
20
The Networking Dilemma Many different networking technologies Many different network applications How do you prevent incompatibilities? 20
21
21 The Problem Re-implement every application for every technology? No! But how does the Internet design avoid this? Skype SSHNFS Radio Coaxial cable Fiber optic Application Transmission Media HTTP
22
22 Solution: Intermediate Layers Introduce intermediate layers that provide set of abstractions for various network functionality and technologies –A new app/media implemented only once –Variation on “add another level of indirection” Skype SSHNFS Packet radio Coaxial cable Fiber optic Application Transmission Media HTTP Intermediate layers
23
23 Computer System Modularity Partition system into modules & abstractions: Well-defined interfaces give flexibility –Hides implementation - can be freely changed, changes are limited in scope –Extend functionality of system by adding new modules –Allows for continuing evolution and innovation E.g., libraries encapsulating set of functionality E.g., programming language + compiler abstracts away how the particular CPU works …
24
Computer System Modularity Well-defined interfaces hide information –Isolate assumptions –Present high-level abstractions But can impair performance! Ease of implementation vs worse performance 24
25
25 Network System Modularity Like software modularity, but: Implementation distributed across many machines (routers and hosts) Must decide: –How to break system into modules Layering –Where modules are implemented End-to-End Principle –Where state is stored Fate-sharing We will address these choices in turn
26
Layering
27
Methodology Break job down into smaller tasks – And understand how they interact Define abstractions for these tasks Then implement them….. 27
28
Tasks in Networking What does it take to send packets across country? Simplistic decomposition: – Task 1: send along a single wire – Task 2: string these together to go across country What makes Task 2 nontrivial? – Routing! More detailed decomposition in next slide…. 28
29
Tasks in Networking (bottom up) Electrons on wire Bits on wire Packets on wire Deliver packets across local network – Local addresses Deliver packets across country – Global addresses Ensure that packets get there Do something with the data 29
30
How do we organize these tasks? Put them into “layers” Layering is a particularly strict form of modularity – Interactions limited to interfaces above and below To motivate layers, we go back to the beginning… 30
31
Question: Who invented layering? 31
32
Answer: Henry Ford Before: – Each person worked on the whole car After: – Each person only handled one particular task – Handed off car to next person in line Only needed to understand the state of the car as it arrived, and only needed to produce the appropriate output – Could remain ignorant of everything else! 32
33
Advantages of Assembly Line Specialization allows people to get faster – i.e., local improvements in implementation If you want to change something in the car, only one person needed to know. – i.e., changes of limited scope 33
34
More Layering in the Real World CEO A writes letter to CEO B – Folds letter and hands it to administrative aide Aide: – Puts letter in envelope with CEO B’s name – Takes to FedEx FedEx Office – Puts letter in larger envelope – Puts name and street address on FedEx envelope – Puts package on FedEx delivery truck FedEx delivers to other company 34 Dear Steve, We give up. Let’s merge. --Bill
35
CEO Aide FedEx CEO Aide FedEx LocationFedex Envelope (FE) The Path of the Letter 35 Letter Envelope Semantic Content Identity “Peers” on each side understand the same things No one else does Lowest level has most packaging
36
The Path Through FedEx 36 Truck Sorting Office Airport FE Sorting Office Airport Truck Sorting Office Airport Crate FE New Crate FE Higher “Stack” at Ends Partial “Stack” During Transit Deepest Packaging at the Lowest Level of Transport Highest Level of “Transit Stack” is Routing
37
How Does This Apply to Networking? Let’s return to task decomposition…. 37
38
Tasks in Networking Electrons on wire Bits on wire Packets on wire Deliver packets across local network – Local addresses Deliver packets across country – Global addresses Ensure that packets get there Do something with the data 38
39
Resulting Layers Electrons on wire (contained in next layer) Bits on wire (Physical) Packets on wire (contained in next layer) Deliver packets across local network (Link) – Local addresses Deliver packets across country (Internetwork) – Global addresses Ensure that packets get there (Transport) Do something with the data (Application) 39
40
Who Does What? Five layers –Lower three layers implemented everywhere –Top two layers implemented only at hosts –What is top layer of router doing? 40 Transport Network Datalink Physical Transport Network Datalink Physical Network Datalink Physical Application Host AHost BRouter
41
Logical Communication Layers interacts with peer’s corresponding layer 41 Transport Network Datalink Physical Transport Network Datalink Physical Network Datalink Physical Application Host AHost BRouter
42
Physical Communication Communication goes down to physical network Then from network peer to peer Then up to relevant layer 42 Transport Network Datalink Physical Transport Network Datalink Physical Network Datalink Physical Application Host AHost BRouter Protocol
43
What Is A Protocol? Protocol: an agreement on how to communicate –To exchange data –To coordinate sharing of resources Protocols specifies syntax and semantics Syntax: how protocol is structured –Format, order messages are sent and received Semantics: what these bits mean –How to respond to various messages, events, etc.
44
Examples of Protocols in Life Asking a question in class Turn-taking in conversations – Pause is a signal for the next person’s response – When do these rules break? Boarding and exiting an airplane – Not all countries have the same protocol! Answering the phone – Starting with hello as signal for other party to talk – Other party identifies themselves, then conversation 44
45
45 Example: HyperText Transfer Protocol GET /courses/archive/spring06/cos461/ HTTP/1.1 Host: www.cs.princeton.edu User-Agent: Mozilla/4.03 CRLF HTTP/1.1 200 OK Date: Mon, 6 Feb 2006 13:09:03 GMT Server: Netscape-Enterprise/3.5.1 Last-Modified: Mon, 6 Feb 2006 11:12:23 GMT Content-Length: 21 CRLF Site under construction Request Response
46
46 Example: IP Packet 4-bit Version 4-bit Header Length 8-bit Type of Service (TOS) 16-bit Total Length (Bytes) 16-bit Identification 3-bit Flags 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Options (if any) Payload 20-byteheader
47
47 Protocol Standardization All hosts must follow same protocol –Very small modifications can make a big difference –Or prevent it from working altogether This is why we have standards –Can have multiple implementations of protocol Internet Engineering Task Force –Based on working groups that focus on specific issues –Produces “Request For Comments” (RFCs) –IETF Web site is http://www.ietf.org –RFCs archived at http://www.rfc-editor.org
48
IP Suite: End Hosts vs. Routers 48 HTTP TCP IP Ethernet interface HTTP TCP IP Ethernet interface IP Ethernet interface Ethernet interface SONET interface SONET interface host router HTTP message TCP segment IP packet
49
Layer Encapsulation 49 Trans: Connection ID Net: Source/DestLink: Src/Dest Appl: Get index.html User AUser B Common case: 20 bytes TCP header + 20 bytes IP header + 14 bytes Ethernet header = 54 bytes overhead
50
Characterizing the Layers (OSI) Service: what a layer does Service interface: how to access the service – Interface for layer above Protocol: how peers communicate – Protocol interface: set of rules and formats that govern the communication between network elements – Determines how the peers achieve the service – Does not govern implementation on a single machine, but how the layer is implemented between machines Examples: layer can have many implementations – This allows innovation! 50
51
Physical Layer (1) Service: move bits between two systems connected by a single physical link Interface: specifies how to send and receive bits –E.g., require quantities and timing Protocols: coding scheme used to represent bits, voltage levels, duration of a bit Examples: Optical, wireless, etc. 51 “Introduction to digital communications” – 67746
52
(Data) Link Layer (2) Service: Enable hosts to exchange messages – Using abstract (but local) addresses – Not just direct physical connections Interface: send messages (frames) to other end hosts; receive messages addressed to end host Protocols: – Routing – Media Access Control (MAC) Examples: – Ethernet, 802.11, Frame Relay, ATM 52 We will start discussing the basics later today
53
(Inter) Network Layer (3) Service: Deliver packets to specified destination – Using abstract global addresses – Inter-network = across multiple layer-2 networks – E.g., from Ethernet to 802.11 to Frame Relay to ATM Interface: send packets to specified internetwork destinations; receive packets destined for end host Protocols: construct routing tables Examples: IP – Why no other examples? 53
54
Transport Layer (4) Service: Communication between processes – Demultiplexing of communication between hosts – Perhaps: reliable transport, rate adaptation Interface: – send message to specific process at given destination – local process receives messages sent to it Protocol: reliability, flow control, packetization of large messages, framing Examples: TCP and UDP – SCTP, T/TCP, DCCP, 54
55
Application Layer (7 - not 5!) Service: any service provided to the end user Interface: depends on the application Protocol: depends on the application Examples: Skype, SMTP (email), HTTP (Web), Halo, BitTorrent … 55
56
The Internet Hourglass 56 Data Link Physical Applications The Hourglass Model Waist There is just one network-layer protocol, IP. The “narrow waist” facilitates interoperability. SMTPHTTPNTPDNS TCPUDP IP EthernetSONET 802.11 Transport FiberCopperRadio
57
Implications of Hourglass Allows arbitrary L2 networks to interoperate – Any networks that support IP can exchange packets Allows applications to function on all networks – Applications that can run on IP can use any network Supports innovations above and below IP – Innovations can be independent, done in parallel But changing IP itself, i.e., IPv6, very hard 57
58
Back to Modularity Modularity in programming: – Set of abstractions Modularity in networking: – Distributed nature of system requires deciding where abstractions are implemented 58
59
Three Basic Architectural Decisions How to break system into modules Where modules are implemented Where state is stored 59
60
Breaking into Modules That is described by layering 60
61
Placing Network Functionality Hugely influential paper: “End-to-End Arguments in System Design” by Saltzer, Reed, and Clark (‘84) –End-to-end principle Basic observation: some types of network functionality can only be correctly implemented end-to-end Because of this, end hosts: –Can satisfy the requirement without network’s help –Must do so, since can’t rely on network’s help Thus, don’t need to implement them in network 61
62
Example: Reliable File Transfer Solution 1: make each step reliable, and string them together to make reliable end-to-end process Solution 2: allow steps to be unreliable, but do end-to-end check and try again if necessary 62 OS Appl. OS Appl. Host AHost B OK
63
Discussion Solution 1 cannot be made perfectly reliable – What happens if a network element misbehaves? – Receiver has to do the check anyway! Solution 2 can also fail, but only if the end system itself fails (i.e., doesn’t follow its own protocol) Solution 2 only relies on what it can control – The endpoint behavior Solution 1 requires endpoints trust other elements – That’s not what reliable means! 63
64
Robust (From Clark’s Paper) As long as the network is not partitioned, two endpoints should be able to communicate Failures (except network partition) should not interfere with endpoint semantics 64
65
Question? Should you ever implement reliability in network? Perhaps, if needed for reasonable efficiency – Don’t aim for perfect reliability, but ok to reduce error rate If individual links fail 10% of the time, and are traversing 10 links, then E2E error rate is 65% Implementing one retransmission on links – Link error rate reduced to 1%, E2E error rate is 9.5% 65
66
Back to the End-to-End Principle Implementing such 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 –E.g., very lossy link 66
67
Conservative Interpretation of E2E Don’t implement a function at the lower levels of the system unless it can be completely implemented at this level Unless you can relieve the burden from hosts, don’t bother 67
68
Radical Interpretation of E2E Don’t implement anything in the network that can be implemented correctly by the hosts –E.g., multicast Make network layer absolutely minimal –E2E principle trumps performance issues –Increases flexibility, since lower layers stay simple 68
69
Important life lessons (partial) Flexibility often more important than performance Architect for flexibility, engineer for performance 69
70
Moderate Interpretation Think twice before implementing functionality in the network If hosts can implement functionality correctly, implement it in 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 70
71
What Does E2E Principle Ignore? There are other stakeholders besides users – ISP might care about the good operation of their network – Various commercial entities – Money-chain might require insertion into the network The need for middlebox functionality – Some functions that, for management reasons, are more easily done in the network. 71
72
Three Basic Architectural Decisions How to break system into modules Where modules are implemented Where state is stored 72
73
Fate-Sharing Note that E2E principles relied on “fate- sharing” – Invariants break only when endpoints themselves break – Minimize dependence on other network elements This should dictate placement of storage 73
74
General Principle: Fate-Sharing When storing state in a distributed system, co- locate it with entities that rely on that state Only way failure can cause loss of the critical state is if the entity that cares about it also fails... –… in which case it doesn’t matter Often argues for keeping network state at end hosts rather than inside routers –In keeping with End-to-End principle –E.g., packet-switching rather than circuit-switching –E.g., NFS file handles, HTTP “cookies” 74
75
Decisions and Their Principles How to break system into modules – Dictated by Layering Where modules are implemented – Dictated by End-to-End Principle Where state is stored – Dictated by Fate-Sharing 75
76
Reminder: Tasks in Networking (bottom up) Electrons on wire Bits on wire Packets on wire Deliver packets across local network – Local addresses Deliver packets across country – Global addresses Ensure that packets get there Do something with the data 76 Not in this course (mostly) The following few weeks The following few weeks Later in the course
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.