490 likes | 503 Views
CS/ECE 438, CSE 425 Communication Networks. Nikita Borisov ECE Department, UIUC. Course Information. Instructor Prof. Nikita Borisov Office Hours: 460 CSL, 244-5385 10-12 Tuesdays nikita@uiuc.edu or by appointment TA Monika Battala, battala2@uiuc.edu Office hours TBA Webpage
E N D
CS/ECE 438, CSE 425Communication Networks Nikita Borisov ECE Department, UIUC
Course Information • Instructor • Prof. Nikita Borisov Office Hours: 460 CSL, 244-5385 10-12 Tuesdays nikita@uiuc.edu or by appointment • TA • Monika Battala, battala2@uiuc.edu • Office hours TBA • Webpage • http://www.cs.uiuc.edu/class/fa06/cs438 • Newsgroup • class.cs438 on news.cs.uiuc.edu UIUC - CS/ECE 438, Fall 2006
Acknowledgments • Slides are adapted from Prof. Kravets • Some material contributed by Profs. Luo, Lumetta, Hajek, Vaidya • Some material from Larry Peterson & James Kurose & Keith Ross UIUC - CS/ECE 438, Fall 2006
Prerequisites • C Programming (CS241) • Pre-req for ECE students is ECE290, but ECE391/398SSL or C experience highly recommended • Probability and Statistics (MATH 461,463 or ECE 413) UIUC - CS/ECE 438, Fall 2006
Textbook • Computer Networks: A Top-Down Approach Featuring the Internet, by Kurose & Ross, 3rd Edition • We will be covering this text out of order • Ch 1 • Ch 5 + some of 6 • Ch 4 • Ch 3 • Some of Ch 2 UIUC - CS/ECE 438, Fall 2006
Recommended Text • UNIX Network Programming, Volume 1, by Stevens • There are 3 editions • Second & third edition more up-to-date • First edition (1990) contains more background on general UNIX programming UIUC - CS/ECE 438, Fall 2006
Grading Policy • Homework 15% • 7 homework assignments • Mid-term Exam 20% • Oct 12 • Programming Projects 35% • 4 Programming projects • 2% off per hour late • Final Exam 30% UIUC - CS/ECE 438, Fall 2006
Homework and Projects • Homeworks: • Due Wednesdays at 2:00 in class. • General extension to Thursdays at 2:00pm (hard deadline). • No questions to TA or on newsgroup after class on Tuesday. • Projects: • Project 1: 5%, Projects 2- 4: 10% • Due Fridays at 9:00pm. UIUC - CS/ECE 438, Fall 2006
Academic Honesty • Your work in this class must be your own. • Penalties for excessive collaboration and cheating are severe • Sharing strategies and small code fragments (5-10 lines) OK • Sharing homework answers and large sections of code forbidden • Don’t post these to newsgroup! • If in doubt, ask the professor UIUC - CS/ECE 438, Fall 2006
One Unit Students • Graduate students MAY take an extra unit project in conjunction with this class • Graduate students • Register for 4 credits • Write a survey paper in a networking research area of your choice. • Project proposal with list of 10+ academic references (no URL’s) due September 22 • Paper due last day of class • Undergraduates may not take this project course UIUC - CS/ECE 438, Fall 2006
Course Objectives • At the end of the semester, you should be able to: • Identify the problems that arise in networked communication • Explain the advantages and disadvantages of existing solutions to these problems in the context of different networking regimes • Understand the implications of a given solution for performance in various networking regimes • Evaluate novel approaches to these problems UIUC - CS/ECE 438, Fall 2006
Programming Objectives • At the end of the semester, you should be able to • Identify and describe the purpose of each component of the TCP/IP protocol suite • Develop solid client-server applications using TCP/IP • Understand the impact of trends in network hardware on network software issues UIUC - CS/ECE 438, Fall 2006
Course Contents • Overview • UNIX Network Programming • Direct Link Networks • Multiple Access • Packet Switched Networks • Internetworking • Reliable Transport • Congestion Control, QoS & Fair Sharing • Performance Analysis and Queueing Theory UIUC - CS/ECE 438, Fall 2006
… Connectivity • Building Block • Links: coax cable, optical fiber, … • Nodes: workstations, routers, … • Links: • Point-to-point • Multiple access UIUC - CS/ECE 438, Fall 2006
Indirect Connectivity • Switched Networks • Internetworks • Recursive definition of a network • Two or more nodes connected by a physical link • Two or more networks connected by one or more nodes UIUC - CS/ECE 438, Fall 2006
Network Problems • What must a network provide? • Connectivity • Cost-effective Resource Sharing • Functionality • Performance UIUC - CS/ECE 438, Fall 2006
Addressing • Addressing • Unique byte-string used to indicate which node is the target of communication • Routing • The process of determining how to forward messages toward the destination node based on its address • Types of Addresses • Unicast: node-specific • Broadcast: all nodes on the network • Multicast: subset of nodes on the network UIUC - CS/ECE 438, Fall 2006
Effects of Indirect Connectivity • Nodes receive data on one link and forward it onto the next -> switching network • Circuit Switching • Telephone • Stream-based (dedicated circuit) • Links reserved for use by communication channel • Send/receive bit stream at constant rate • Packet Switching • Internet • Message-based (store-and-forward) • Links used dynamically • Admission policies and other traffic determine bandwidth UIUC - CS/ECE 438, Fall 2006
Cost-Effective Sharing of Resources • Physical links and switches must be shared among many users • Common multiplexing strategies • (Synchronous) time-division multiplexing (TDM) • Frequency-division multiplexing (FDM) UIUC - CS/ECE 438, Fall 2006
Example: 4 users FDM frequency time TDM frequency time Circuit Switching: FDM and TDM UIUC - CS/ECE 438, Fall 2006
Statistical Multiplexing • Statistical Multiplexing (SM) • On-demand time-division multiplexing • Scheduled on a per-packet basis • Packets from different sources are interleaved • Uses upper bounds to limit transmission • Queue size determines capacity per source UIUC - CS/ECE 438, Fall 2006
… Statistical Multiplexing in a Switch • Packets buffered in switch until forwarded • Selection of next packet depends on policy • How do we make these decisions in a fair manner? Round Robin? FIFO? • How should the switch handle congestion? UIUC - CS/ECE 438, Fall 2006
Functionality • Support For Common Services • Goal • Meaningful communication between hosts on a network • Idea • Common services simplify the role of applications • Hide the complexity of the network without overly constraining the application designer • Semantics and interface depend on applications • Request/reply: FTP, HTTP, DNS • Message stream: video-on-demand, video conferencing UIUC - CS/ECE 438, Fall 2006
Host Host APP Channel Channel Host APP Host Host Channels • Channel • The abstraction for application-level communication • Idea • Turn host-to-host connectivity into process-to-process communication UIUC - CS/ECE 438, Fall 2006
Channel Implementation • Question • Where does the functionality belong? • Middle (switches)? • Telephone system • Edges (end hosts)? • Internet UIUC - CS/ECE 438, Fall 2006
Inter-process Communication • Problems typically masked by communication channel abstractions • Bit errors (electrical interference) • Packet errors (congestion) • Link/node failures • Message delays • Out-of-order delivery • Eavesdropping • Goal • Fill the gap between what applications expect and what the underlying technology provides UIUC - CS/ECE 438, Fall 2006
Performance ... and to do so while delivering “good” performance. • Bandwidth/throughput • Data transmitted per unit time • Example: 10 Mbps • Link bandwidth vs. end-to-end bandwidth • Notation • KB = 210 bytes • Mbps = 106 bits per second UIUC - CS/ECE 438, Fall 2006
Performance • Latency/delay • Time from A to B • Example: 30 msec (milliseconds) • Many applications depend on round-trip time (RTT) • Components • Transmission time • Propagation delay over links • Queueing delays • Software processing overheads UIUC - CS/ECE 438, Fall 2006
Performance Notes • Speed of Light • 3.0 x 108 meters/second in a vacuum • 2.3 x 108 meters/second in a cable • 2.0 x 108 meters/second in a fiber • Comments • No queueing delays in a direct link • Bandwidth is not relevant if size = 1bit • Software overhead can dominate when distance is small • Key Point • Latency dominates small transmissions • Bandwidth dominates large UIUC - CS/ECE 438, Fall 2006
Delay Bandwidth Delay x Bandwidth Product • channel = pipe • delay = length • bandwidth = area of a cross section • bandwidth x delay product = volume UIUC - CS/ECE 438, Fall 2006
Delay x Bandwidth Product • Example: Transcontinental Channel • BW = 45 Mbps • delay = 50ms • bandwidth x delay product = (45 x 106 bits/sec) x (50 x 10–3 sec) = 2.25 x 106 bits • Bandwidth x delay product • How many bits the sender must transmit before the first bit arrives at the receiver if the sender keeps the pipe full • Takes another one-way latency to receive a response from the receiver UIUC - CS/ECE 438, Fall 2006
100 Mbps 1 Mbps 25MB 1Mbps 1b 1Mbps 100ms 1ms Bandwidth vs. Latency • Relative importance • 1-byte: Latency bound • 1ms vs 100ms latency dominates 1Mbps vs 100Mbps BW • 25MB: Bandwidth bound • 1Mbps vs 100Mbps BW dominates 1ms vs 100ms latency UIUC - CS/ECE 438, Fall 2006
Bandwidth vs. Latency • Infinite bandwidth • RTT dominates • Throughput = TransferSize / TransferTime • TransferTime = RTT + 1/Bandwidth x TransferSize • Its all relative • 1-MB file to 1-Gbps link looks like a 1-KB packet to 1-Mbps link UIUC - CS/ECE 438, Fall 2006
Network Architecture • Challenge • Fill the gap between hardware capabilities and application expectations, and to do so while delivering “good” performance. • Hardware and expectations are moving targets. • How do network designers cope with complexity? • Layering • Protocols • Standards UIUC - CS/ECE 438, Fall 2006
Application programs Message stream channel Request/reply channel Host-to-host connectivity Hardware Abstraction through Layering • Abstract system into layers: • Decompose the problem of building a network into manageable components • Each layer provides some functionality • Modular design provides flexibility • Modify layer independently • Allows alternative abstractions UIUC - CS/ECE 438, Fall 2006
Protocols • Definition • A protocol is an abstract object that makes up the layers of a network system • A protocol provides a communication service that higher-layer objects use to exchange messages • Service interface: • To objects on the same computer that want to use its communication services • Peer interface: • To its counterpart on a different machine. peers communicate using the services of lower-level protocols UIUC - CS/ECE 438, Fall 2006
Higher-level protocol (TCP) Higher-level protocol (TCP) Service interface Lower-level Protocol (IP) Lower-level Protocol (IP) Peer-to-peer interface Interfaces Host1 Host2 UIUC - CS/ECE 438, Fall 2006
Terminology • Term “protocol” is overloaded • specification of peer-to-peer interface • module that implements this interface UIUC - CS/ECE 438, Fall 2006
Layering Concepts • Encapsulation • Higher layer protocols create messages and send them via the lower layer protocols • These messages are treated as data by the lower-level protocol • Higher-layer protocol adds its own control information in the form of headers or trailers • Multiplexing and Demultiplexing • Use protocol keys in the header to determine correct upper-layer protocol UIUC - CS/ECE 438, Fall 2006
Application program Application program DATA DATA Request/ Reply Request/ Reply RRP HDR DATA RRP HDR DATA Host-to-Host Host-to-Host HHP HDR RRP HDR DATA Encapsulation UIUC - CS/ECE 438, Fall 2006
OSI Architecture • Open Systems Interconnect (OSI) Architecture • International Standards Organization (ISO) • International Telecommunications Union (ITU, formerly CCITT) • “X dot” series: X.25, X.400, X.500 • Primarily a reference model UIUC - CS/ECE 438, Fall 2006
OSI Protocol Stack • Application: Application specific protocols • Presentation: Format of exchanged data • Session: Name space for connection mgmt • Transport: Process-to-process channel • Network: Host-to-host packet delivery • Data Link: Framing of data bits • Physical: Transmission of raw bits Application Presentation Session Transport Network Data Link Physical UIUC - CS/ECE 438, Fall 2006
OSI Protocol Stack Application Application Host User-Level Presentation Presentation Session Session Router Transport Transport Host OS Kernel Network Network Network Data Link Data Link Data Link Physical Physical Physical UIUC - CS/ECE 438, Fall 2006
Internet Architecture • Internet Architecture (TCP/IP) • Developed with ARPANET and NSFNET • Internet Engineering Task Force (IETF) • Culture: implement, then standardize • OSI culture: standardize, then implement • Popular with release of Berkeley Software Distribution (BSD) Unix; i.e., frees software • Standard suggestions debated publicly through “requests for comments” (RFC’s) • We reject kings, presidents, and voting. We believe in rough consensus and running code. – David Clark UIUC - CS/ECE 438, Fall 2006
Internet Architecture – Hourglass Design FTP HTTP DNS VoIP TCP UDP IP Ethernet FDDI ATM Modem UIUC - CS/ECE 438, Fall 2006
Application TCP UDP IP Network Internet Architecture • Features: • No strict layering • Hourglass shape – IP is the focal point UIUC - CS/ECE 438, Fall 2006
Protocol Acronyms • (T)FTP - (Trivial) File Transfer Protocol • HTTP - HyperText Transport Protocol • DNS - Domain Name Service • SMTP – Simple Mail Transfer Protocol • NTP - Network Time Protocol • TCP - Transmission Control Protocol • UDP - User Datagram Protocol • IP - Internet Protocol • FDDI - Fiber Distributed Data Interface • ATM - Asynchronous Transfer Mode UIUC - CS/ECE 438, Fall 2006
Summary • Goal • Understanding of computer network functionality, with experience building and using computer networks • Steps • Identify what concepts we expect from a network • Define a layered architecture • Implement network protocols and application programs UIUC - CS/ECE 438, Fall 2006
Assignments • Homework 1 • Due Wednesday September 6 at 2:00pm. • Project 1 • Due Friday September 8 at 9:00pm. • Both will be on website by end of day today. UIUC - CS/ECE 438, Fall 2006