CMPE 150 Fall 2005 Lecture 28

1. CMPE 150Fall 2005Lecture 28 Introduction to Computer Networks

2. Announcements • Homework 5 posted. • Due, Mon, 12.05. • Final exam: December 7th. 4-7pm • In class. • Closed books/notes. • Comprehensive. • Discussion session: • Monday, 12.05 @ 2pm. • Jack’s lounge. • Questions by e-mail. • Course evaluation. • Today. • CE 151 will be offered in Winter 06! • Likely TTh 4-5:45.

3. Today • Transport Layer (Cont’d). • Chapter 6 of Tanenbaum. • Application layer.

4. TCP Congestion Control

5. Network dynamics delay throughput load load

6. TCP Self-Clocking Pr Pb receiver sender Ab As Ar

7. Congestion Control Design • Avoidance or detection/recovery? • Avoidance keeps system at knee of curve • Requires some congestion signal. • Detection/recovery responds to loss after the fact. • TCP • Which is TCP? • Congestion detection/recovery. • How does TCP do it? • Slow start, congestion avoidance, exponential backoff.

8. TCP congestion control basics • Like, flow control, also window based. • Sender keeps congestion window (cwin). • Each sender keeps 2 windows: receiver’s advertised window and congestion window. • Sender’s maximum window: min(advertised window, cwin). • Sender’s actual window: • Max window - unacknowledged segments.

9. TCP congestion control mechanisms • Collection of interrelated mechanisms: • Slow start. • Congestion avoidance. • Accurate retransmission timeout estimation. • Fast retransmit. • Fast recovery.

10. TCP congestion window • New congestion window cwnd. • What the network can handle, • versus flow control window (wnd): what the other end can handle. • Actual congestion window: • min (wnd, cwnd).

11. When to increase/decrease? A control theory problem: Observe network. Reduce window if congested. Increase window if not congested. Constraints: Efficiency. Fairness. Stability (too much oscillation is bad). Out-of-date info RTT is fundamental limit to how quickly you can react How to adjust window?

12. Slow start [Jacobson 1988] • How do we get this self-clocking behavior to start? • Initialize cwnd = 1. • Upon receipt of every ack, cwnd = cwnd + 1 • Implications • Window actually increases in RTT * log2W (exponential increase). • Can overshoot window and cause packet loss. • Connection’s congestion window starts at 1 segment.

13. Slow start example one RTT 0R 1 one pkt time 1R 1 2 3 2R 2 3 4 6 5 7 3R 4 5 6 7 8 10 12 14 9 11 13 15

14. When to End Slow-Start? • Want to end when the pipe is full. • When cwnd > ssthresh. • Start with large ssthresh, but then refine it. • On packet loss. • cwnd=1 and go back to slow start. • ssthresh = cwnd / 2 • assume that pipe size was somewhere between last good window (cwnd/2) and current window (cwnd). • Eventually, ssthresh is right and transition to congestion avoidance without packet loss.

15. Congestion avoidance • Upon receiving ACK • Increase cwnd by 1/cwnd. • This is additive increase. • Why not multiplicative increase? • Growing too fast in equilibrium => oscillations

16. TCP Congestion Control: Operation cwin timeout threshold threshold time

17. TCP Retransmission Timer • When segment sent, retransmission timer starts. • If segment ACKed, timer stops. • If time out, segment retransmitted and timer starts again.

18. How to set timer? • Based on round-trip time: time between a segment is sent and ACK comes back. • If timer is too short, unnecessary retransmissions. • If timer is too long, long retransmission delay.

19. Jacobson’s Algorithm • Determining the round-trip time: • TCP keeps RTT variable. • When segment sent, TCP measures how long it takes to get ACK back (M). • RTT = alpha*RTT + (1-alpha)M. • alpha: smoothing factor; determines weight given to previous estimate. • Typically, alpha=7/8.

20. Jacobson’s Algorithm (Cont’d) • Determining timeout value: • Measure RTT variation, or |RTT-M|. • Keeps smoothed value of cumulative variation D=alpha*D+(1-alpha)|RTT-M|. • Alpha may or may not be the same as value used to smooth RTT. • Timeout = RTT+4*D.

21. Karn’s Algorithm • How to account for ACKs of retransmitted segments? • Count it for first or second transmission? • Karn proposed not to update RTT on any retransmitted segment. • Instead RTT is doubled on each failure until segments get through.

22. Application Layer • Tanenbaum, Chapter 7.

23. DNS

24. What’s DNS? • Domain Name System. • What does it do? • Maps host names to IP addresses, and • Vice-versa.

25. Some History • Original approach (ARPANET, 1970’s): • File hosts.txt listed all hosts and their IP addresses. • Every night every host fetches file from central repository. • OK for a few hundred hosts. • Scalability? • File size. • Centrally managed.

26. DNS • Hierarchical name space. • Distributed database. • RFCs 1034 and 1035.

27. How is it used? • Client-server model. • Client DNS (running on client hosts), or “resolver”. • Application calls “resolver” with name. • “Resolver” contacts local DNS server (using UDP) passing the name. • Server returns corresponding IP address.

28. DNS Name Space • A portion of the Internet domain name space.

29. Name Space Structure • Top-level domains: • Generic. • Countries. • Leaf domains: no sub-domains. • In practice all US organizations are under a generic domain, while everything outside the US is under the corresponding country domain.

30. DNS Names • Domain names: • Concatenation of all domain names starting from its own all the way to the root separated by “.”. • Refers to a tree node and all names under it. • Case insensitive. • Components up to 63 characters. • Full name less than 255 characters.

31. Name Space Management • Domains are autonomous. • Organizational boundaries. • Each domain manages its own name space independently of other domains. • Delegation: • When creating new domain: register with parent domain. • For name uniqueness. • For name resolution.

32. Name Servers • Entire database in a single name server. • Practical? • Why? • DNS database is partitioned into zones. • Each zone contains part of the DNS tree. • Zone <-> name server. • Each zone may be served by more than 1 server. • A server may serve multiple zones. • Primary and secondary name servers.

33. Name Servers • Part of the DNS name space showing the division into zones.

34. Name Resolution • Application wants to resolve name. • Resolver sends query to local name server. • Resolver configured with list of local name servers. • Select servers in round-robin fashion. • If name is local, local name server returns matching authoritative RRs. • Authoritative RR comes from authority managing the RR and is always correct. • Cached RRs may be out of date.

35. Name Resolution (Cont’d) • If information not available locally (not even cached), local NS will have to ask someone else. • It asks the server of the top-level domain of the name requested.

36. More on Name Resolution • How a resolver looks up a remote name in eight steps.

37. Recursive Resolution • Recursive query: • Each server that doesn’t have info forwards it to someone else. • Response finds its way back. • Alternative: • Name server not able to resolve query, sends back the name of the next server to try. • Some servers use this method. • More control for clients.

38. Example • Suppose resolver on flits.cs.vu.nl wants to resolve linda.cs.yale.edu. • Local NS, cs.vu.nl, gets queried but cannot resolve it. • It then contacts .edu server. • .edu server forwards query to yale.edu server. • yale.edu contacts cs.yale.edu, which has the authoritative RR. • Response finds its way back to originator. • cs.vu.nl caches this info. • Not authoritative (since may be out-of-date). • RR TTL determines how long RR should be cached.

39. Resource Records • Entry in the DNS database. • Several types of entries or RRs. • Example: RR “A” contains IP address. • Name <-> several resource records. • RR format: five-tuple. • Name. • TTL (in seconds). • Class (usually “IN” for Internet info). • Type: type of RR. • Value.

40. Resource Records • The principal DNS resource records types.

41. The Web and HTTP

42. Some History • Started in 1989 at CERN, European center for nuclear research, in Switzerland. • Original motivation: need for scientists around the world to collaborate and share multi-media information. • Tim Berners-Lee came up with initial proposal of a web of linked documents

43. More History… • First text-based prototype demo in 12.91. • Release of first graphical interface, Mosaic, in 02.93 at NCSA by M. Andreessen. • In 1994, Andreessen creates Netscape. • In 1994, CERM and MIT set up the WWW Consortium to further develop the Web. • www.w3.org for more information.

44. The Web • WWW, or the world-wide web is a resource discovery service. • Resource space is organized hierarchically, and resources are linked to one another according to some relation. • Hypertext organization: link “granularity”; allows links within documents. • Graphical user interface.

45. The client side • Users perceive the Web as a vast collection of information. • Page is the Web’s information transfer unit. • Each page may contain links to other pages. • Users follow links by clicking on them which takes them to the corresponding page. • This process can go on indefinetly, traversing several pages located in different places.

46. The browser • Program running on client that retrieves and displays pages. • Interacts with server of page. • Interprets commands and displays page. • Examples: Mosaic, Netscape’s Navigator and Communicator, Microsoft Internet Explorer. • Other features: back, forward, bookmark, caching, handle multimedia objects.

47. The Server Side • Web site has Web server running that answers requests for pages locally served. • Web server listens to port 80 for requests. • When request from client arrives, connection is set up. • Server replies. • Connection released.

48. Example • User clicked on www.w3.org/hypertext/WWW/TheProject.html.

49. Example (cont’d) • Browser asks DNS to resolve www.w3.org. • DNS replies with 18.23.0.23. • Browser sets up connection to 18.23.0.23 port 80. • Browser sends GET /hypertext/WWW/TheProject.html. • www.w3.org server sends TheProject.html file. • Connection released. • Browser displays TheProject.html, fetching and displaying all embedded objects (images, etc).

50. Observations • Many browsers display status information at bottom of the screen. • For each embedded object (in-line image like icon, picture, etc), browser establishes new connection. • Performance hit. • Revisions to protocol (HTTP) address this.