1. CMSC 23300/33300 Computer Networks Spring 2006 (Tu, Th 1:30-2:50 in Ry 251) Lecturer: Ian Foster Teaching Assistants: George Kuan, Ido Rosen, Ioan Raicu, Xuehai Zhang http://dsl.cs.uchicago.edu/Courses/CMSC33300 ?

2. 2 Goals for Today’s Class l Course overview u Goals u Structure u Learning the material u Labs, projects, etc. u Course grading u Academic policies l Key concepts in data networking u Protocols u Layering u Resource allocation u Naming

3. 3 What You Learn in This Course l Skill: network programming u Socket programming u Designing and implementing protocols l Knowledge: how the Internet works u IP protocol suite u Internet architecture u Applications (Web, e-mail, P2P, VoIP, …) l Insight: key concepts in networking u Protocols u Layering u Resource allocation u Naming

4. 4 Course Structure l Start at the top u Protocols: essential elements l Then study the “narrow waist” of IP u IP best-effort packet-delivery service u IP addressing and packet forwarding l And how to build on top of the narrow waist u Sockets: how applications view the Internet u Transport protocols (TCP, UDP) u Domain Name System (DNS) u Glue (ARP, DHCP, ICMP) u End-system security and privacy (NAT, firewalls) l Looking underneath IP u Link technologies (Ethernet, wireless, …)

5. 5 Course Structure (Contd.) l How to get the traffic from here to there u Internet routing architecture (the “inter” in Internet) u Intradomain and interdomain routing protocols l Building applications u Web and content-distribution networks u E-mail u Peer-to-peer file sharing u Multimedia streaming and voice-over-IP l Security l Other approaches to building networks (maybe) u Circuit switching (e.g., ATM, MPLS, …) u More on wireless networks, multicast, …

6. 6 People l Lecturer: Ian Foster u Research Institutes, Room 405 u Email: foster@cs.uchicago.edu u Office hours 3-4pm Tuesday, and by appointment l Teaching Assistants: u George Kuan: gkuan@cs.uchicago.edu u Ido Rosen: ido@cs.uchicago.edu u Ioan Raicu: iraicu@cs.uchicago.edu u Xuehai Zhang: hai@cs.uchicago.edu u See class Web for office hours

7. 7 Communications l Web site u http://dsl.cs.uchicago.edu/Courses/CMSC33300 u Slides, reading list, other information l Mailing list u cmsc33300@mailman.cs.uchicago.edu u Sign up: http://mailman.cs.uchicago.edu/mailman/listinfo/cmsc 33300 u Read often, & ask (& answer!) questions

8. 8 The Course in a Nutshell: Lectures, Quizzes, Labs, and Projects l Lectures (20 in total) u Based closely on Computer Networks: A Systems Approach, 3rd Edition (Peterson, Davie) l Quizzes (10 in total; 20% of final grade) u Each Thursday, a 10 minute quiz u Covers material presented in previous week(s) l Labs (8 in total; 25% of final grade) u Using OpNet simulation tool u Network Simulation Experiments Manual (Aboelela) l Projects (4 in total: 39% of final grade) u Measuring networks (0.5 week) (4 points) u Writing a Packet Analyzer (2 weeks) (8 points) u Reliable communication over UDP (3 weeks) (16 points) u Build an HTTP Server (4 weeks) (20 points)

9. 9 Graduate Students: An Additional Component l Homeworks (4 in total, 16% of final grade [undergrads will have the other 84% scaled to 100%]) u Involve reading, and answering questions on, technical articles u First homework due in 2 weeks l More details available online

10. 10 Books and Other Materials l Required textbook u Computer Networks: A Systems Approach (3rd Edition), by Peterson & Davie l Experiment manual u Network Simulation Experiments Manual, Aboelela u Accessible online if you buy a new copy of Peterson & Davie l Online resources and handouts u E.g., on socket programming u Recommended additional reading

11. 11 Policies: Write Your Own Code Programming in an individual creative process much like composition. You must reach your own understanding of the problem and discover a path to its solution. During this time, discussions with friends are encouraged. However, when the time comes to write code that solves the problem, such discussions are no longer appropriate - the program must be your own work. If you have a question about how to use some feature of C, UNIX, etc., you can certainly ask your friends or the TA, but do not, under any circumstances, copy another person's program. Letting someone copy your program or using someone else's code in any form is a violation of academic regulations. “Using someone else’s code” includes using solutions or partial solutions to assignments provided by commercial web sites, instructors, preceptors, teaching assistants, friends, or students from any previous offering of this course or any other course.

12. 12 Four Key Concepts in Networking l Protocols u Speaking the same language u Syntax and semantics l Layering u Standing on the shoulders of giants u A key to managing complexity l Resource allocation u Dividing scare resources among competing parties u Memory, link bandwidth, wireless spectrum, paths, … u Distributed vs. centralized algorithms l Naming u What to call computers, services, protocols, …

13. 13 Concept 1: Protocols Calendar Service l Making an appointment with your advisor l Specifying the messages that go back and forth u And an understanding of what each party is doing Please meet with me for 1.5 hours starting at 1:30pm on February 8, 2006? I can’t. Yes! Please meet with me for 1.5 hours starting at 3:00pm on February 8, 2006? Please meet with me for 1.5 hours starting at 4:30pm on February 8, 2006?

14. 14 Okay, So This is Getting Tedious l You: When are you free to meet for 1.5 hours during the next two weeks? l Advisor: 10:30am on Feb 8 and 1:15pm on Feb 9. l You: Book me for 1.5 hours at 10:30am on Feb 8. l Advisor: Yes.

15. 15 Well, Not Quite Enough l Student #1: When can you meet for 1.5 hours during the next two weeks? l Advisor: 10:30am on Feb 8 and 1:15pm on Feb 9 l Student #2: When can you meet for 1.5 hours during the next two weeks? l Advisor: 10:30am on Feb 8 and 1:15pm on Feb 9 l Student #1: Book me for 1.5 hours at 10:30am on Feb 8. l Advisor: Yes l Student #2: Book me for 1.5 hours at 10:30am on Feb 8. l Advisor: Uh… well… I can no longer can meet then. I’m free at 1:15pm on Feb 9 l Student #2: Book me for 1.5 hours at 1:15pm on Feb 9. l Advisor: Yes

16. 16 Specifying the Details l How to identify yourself? u Name? Social security number? l How to represent dates and time? u Time, day, month, year? In what time zone? u Number of seconds since Jan 1, 1970? l What granularities of times to use? u Any possible start time & meeting duration? u Multiples of five minutes? l How to represent the messages? u Strings? Record with name, start time, & duration? l What do you do if you don’t get a response? u Ask again? Reply again?

17. 17 Protocol Example: HyperText Transfer Protocol GET / Courses/CMSC33300 / HTTP/1.1 Host: dsl.cs.uchicago.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

18. 18 Protocol Example: Internet Protocol (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-byte header

19. 19 IP: Best-Effort Packet Delivery l Packet switching u Send data in packets u Header with source & destination address l Best-effort delivery u Packets may be lost u Packets may be corrupted u Packets may be delivered out of order source destination IP network

20. 20 Protocol Example: Transmission Control Protocol (TCP) l Communication service (socket) u Ordered, reliable byte stream u Simultaneous transmission in both directions l Key mechanisms at end hosts u Retransmit lost and corrupted packets u Discard duplicate packets and put packets in order u Flow control to avoid overloading the receiver buffer u Congestion control to adapt sending rate to network load sourcenetworkdestination TCP connection

21. 21 Protocol Standardization l Communicating hosts speaking the same protocol u Standardization to enable multiple implementations u Or, the same folks have to write all the software l Standardization: Internet Engineering Task Force u Based on working groups that focus on specific issues u Produces “Request For Comments” (RFCs) l Promoted to standards via rough consensus and running code l E.g., RFC 959 on “File Transfer Protocol” for Assignment #1 u IETF Web site is http://www.ietf.org l De facto standards: same folks writing the code u P2P file sharing, Skype, …

22. 22 Concept 2: Layering A Modular Approach l Sub-divide the problem u Each layer relies on services from layer below u Each layer exports services to layer above l Interface between layers defines interaction u Hides implementation details u Layers can change without disturbing other layers Link hardware Host-to-host connectivity Application-to-application channels Application

23. 23 IP Suite: End Hosts vs. Routers HTTP TCP IP Ethernet interface HTTP TCP IP Ethernet interface IP Ethernet interface SONET interface SONET interface host router HTTP message TCP segment IP packet Ethernet interface

24. 24 The Internet Protocol Suite UDPTCP Data Link Physical Applications The Hourglass Model Waist The waist facilitates interoperability FTPHTTPTFTPNV TCPUDP IP NET 1 NET 2 NET n …

25. 25 Layer Encapsulation Get index.html Connection ID Source/Destination Link Address User AUser B

26. 26 Problem: Packet size Solution: Split the data across multiple packets What if the Data Doesn’t Fit? l On Ethernet, max IP packet is 1500 bytes l Typical Web page is 10 kbytes GETindex.html GET index.html

27. 27 Protocol Demultiplexing l Multiple choices at each layer FTPHTTPTFTPNV TCPUDP IP NET 1 NET 2 NET n … TCP/UDPIP Port Number Network Protocol Field Type Field

28. 28 Demultiplexing: Port Numbers l Differentiate between multiple transfers u Knowing source and destination host is not enough u Need an id for each transfer between the hosts l Specify a particular service running on a host u E.g., HTTP server running on port 80 u E.g., FTP server running on port 21 HTTP transfers FTP transfer

29. 29 Is Layering Harmful? l Layer N may duplicate lower level functionality u E.g., error recovery to retransmit lost data l Layers may need same information u E.g., timestamps, maximum transmission unit size l Strict adherence to layering may hurt performance u E.g., hiding details about what is really going on l Some layers are not always cleanly separated u Inter-layer dependencies for performance reasons u Some dependencies in standards (header checksums) l Headers start to get really big u Sometimes more header bytes than actual content

30. 30 Resource Allocation: Queues l Sharing access to limited resources u E.g., a link with fixed service rate l Simplest case: first-in-first out queue u Serve packets in the order they arrive u When busy, store arriving packets in a buffer u Drop packets when the queue is full

31. 31 What if the Data gets Dropped? Internet GET index.html Problem: Lost Data Internet GET index.html Solution: Timeout and Retransmit GET index.html

32. 32 Solution: Add Sequence Numbers Problem: Out of Order What if the Data is Out of Order? GETx.htindeml GET x.htindeml GET index.html ml4inde2x.ht3GET1

33. 33 Concept 3: Resource Allocation Congestion Control l What if too many folks are sending data? u Senders agree to slow down their sending rates u … in response to their packets getting dropped l The essence of TCP congestion control u Key to preventing congestion collapse of the Internet

34. 34 Transmission Control Protocol l Flow control: window-based u Sender limits number of outstanding bytes (window size) u Receiver window ensures data does not overflow receiver l Congestion control: adapting to packet losses u Congestion window tries to avoid overloading the network (increase with successful delivery, decrease with loss) u TCP connection starts with small initial congestion window time congestion window slow start congestion avoidance

35. 35 Concept 4: Naming Domain Name System (DNS) l Properties of DNS u Hierarchical name space divided into zones u Translation of names to/from IP addresses u Distributed over a collection of DNS servers l Client application u Extract server name (e.g., from the URL) u Invoke system call to trigger DNS resolver code l E.g., gethostbyname() on “www.cs.uchicago.edu” l Server application u Extract client IP address from socket u Optionally invoke system call to translate into name l E.g., gethostbyaddr() on “12.34.158.5”

36. 36 Domain Name System comeduorgac uk zw arpa unnamed root bar westeast foomy ac cam usr in- addr 12 34 56 generic domainscountry domains my.east.bar.edu usr.cam.ac.uk 12.34.56.0/24

37. 37 DNS Resolver and Local DNS Server Application DNS resolver Local DNS server 1 10 DNS cache DNS query 2 DNS response 9 Root server 3 4 Top-level domain server 5 6 Second-level domain server 7 8 Caching based on a time-to-live (TTL) assigned by the DNS server responsible for the host name to reduce latency in DNS translation.

38. 38 An Aside: TTL and Traceroute 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-byte header

39. 39 Time-to-Live (TTL) Field l Potential robustness problem u Forwarding loops can cause packets to cycle forever u Confusing if the packet arrives much later l Time-to-live field in packet header u TTL field decremented by each router on the path u Packet is discarded when TTL field reaches 0… u …and “time exceeded” message is sent to the source

40. 40 Application of TTL in Traceroute l Time-To-Live field in IP packet header u Source sends a packet with a TTL of n u Each router along the path decrements the TTL u “TTL exceeded” sent when TTL reaches 0 l Traceroute tool exploits this TTL behavior source destination TTL=1 Time exceeded TTL=2 Send packets with TTL=1, 2, … and record source of “time exceeded” message

41. 41 Example Traceroute: Berkeley to CNN 1 169.229.62.1 2 169.229.59.225 3 128.32.255.169 4 128.32.0.249 5 128.32.0.66 6 209.247.159.109 7 * 8 64.159.1.46 9 209.247.9.170 10 66.185.138.33 11 * 12 66.185.136.17 13 64.236.16.52 Hop number, IP address, DNS name inr-daedalus-0.CS.Berkeley.EDU soda-cr-1-1-soda-br-6-2 vlan242.inr-202-doecev.Berkeley.EDU gigE6-0-0.inr-666-doecev.Berkeley.EDU qsv-juniper--ucb-gw.calren2.net POS1-0.hsipaccess1.SanJose1.Level3.net ? pos8-0.hsa2.Atlanta2.Level3.net pop2-atm-P0-2.atdn.net ? pop1-atl-P4-0.atdn.net www4.cnn.com No response from router No name resolution

42. 42 Try Running Traceroute Yourself l On UNIX machine u Traceroute u E.g., “traceroute www.cnn.com” or “traceroute 12.1.1.1” l On Windows machine u Tracert u E.g., “tracert www.cnn.com” or “tracert 12.1.1.1” l Common uses of traceroute u Discover the topology of the Internet u Debug performance and reachability problems

43. 43 Summary l Course objectives u Network programming u How the Internet works u Key concepts in networking l Key concepts in networking u Protocols u Layers u Resource allocation u Naming

44. 44 Next l For you to do u Read Chapter 1 of Peterson/Davie, but don’t worry about sockets for now u Complete first project by Wednesday midnight u Complete first lab (due in 1 week) u Grad students: start first homework (due in 2 weeks) u First quiz on Thursday l Next lecture: packet switching u Read Sections 3.1, 3.4 of Peterson & Davie