1 / 24

CSE 30264 Computer Networks

CSE 30264 Computer Networks. Prof. Aaron Striegel Department of Computer Science & Engineering University of Notre Dame Lecture 19 – March 23, 2010. Today’s Lecture. Project 2 Q&A Project 3 Overview Transport TCP Congestion Control . Application. Transport. Network. Data.

hana
Download Presentation

CSE 30264 Computer Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSE 30264Computer Networks Prof. Aaron Striegel Department of Computer Science & Engineering University of Notre Dame Lecture 19 – March 23, 2010

  2. Today’s Lecture • Project 2 • Q&A • Project 3 • Overview • Transport • TCP Congestion Control Application Transport Network Data Physical CSE 30264

  3. Project 2 • Last questions? CSE 30264

  4. Project 3 • Flex your network socket muscles • Peer to peer system • Search / share binary files • Two components • Client • Tracker Due: Tuesday, April 13 @ 5 PM CSE 30264

  5. Project 3 • Operational order • Client starts up • irishP2P ServerIPServerPortMaxPeers • Client connects to tracker • Client gets list of other clients (IPs, ports) • Client connects to a subset of other clients (MaxPeers) • Client can search for / retrieve files CSE 30264

  6. Project 3 - Tracker • Who are the people in my neighborhood? • Simple list • IP, Port • Supports two operations • Client can retrieve the list of other clients • Client can join the list at the server Optional / EC: Make a keep alive between the client and the tracker CSE 30264

  7. Project 3 - Client • Key functionality • Bootstrap • Figure out who other clients are • Connect to the server • Command prompt • Take commands from user • Search • Try to find a file at the other locations • Get • Download the file from the other locations • Server for other clients • Respond to their search requests CSE 30264

  8. Project 3 - Search • Simple search dynamics • Search only immediate peers • Look only at file name • Assume file name is descriptive > search *Peas*.mp3 Searching for *Peas*.mp3 Querying Peer 1: Yes, successful! Track 1 – Peas.mp3 Track 2 – Peas.mp3 Querying Peer 2: No results CSE 30264

  9. Project 3 - Retrieval • Request a file for transfer from the client • Transfer via binary • Up to you how to transfer > get “Track 1 - Peas.mp3” 1 Contacting Peer 1 for information Success – file exists, 1278920 bytes File downloaded, 789.5kB / sec > CSE 30264

  10. Project 3 - Client • Multiple pthreads • Main thread watching the command prompt • Thread watching for new client requests (new conns) • Thread handling existing clients Need to demonstrate three active clients CSE 30264

  11. Project 3 – Extended Features • 5% of project grade • Several features ideas • Keep alive with tracker • Tracker notification of client leaving • Search / fetch option • Ability to fetch only part of a file from a client • Ability to queue requests while continuing to work • Health / status of existing peers • Prevention of freeloading CSE 30264

  12. Congestion Control Outline Congestion Avoidance RED TCP Vegas CSE30264

  13. Congestion Avoidance • TCP’s strategy • Control congestion once it happens • Repeatedly increase load in an effort to find the point at which congestion occurs, and then back off • Alternative strategy • Predict when congestion is about to happen • Reduce rate before packets start being discarded • Call this congestion avoidance, instead of congestion control • Two possibilities • Router-centric: DECbit and RED Gateways • Host-centric: TCP Vegas CSE30264

  14. DECbit • Add binary congestion bit to each packet header • Router • Monitors average queue length over last busy+idle cycle • Set congestion bit if average queue length >= 1 • Attempts to balance throughput against delay CSE30264

  15. End Hosts • Destination echoes bit back to source • Source records how many packets resulted in set bit • If less than 50% of last window’s worth had bit set • increase CongestionWindow by 1 packet • If 50% or more of last window’s worth had bit set • decrease CongestionWindow by 0.875 times CSE30264

  16. Expedited Congestion Notification • ECN – Expedited Congestion Notification • DECbit realized • Two bit congestion notification • Enabled bit • Actual setting • Support in Linux kernel • What does it say? Are there any problems with it? CSE 30264

  17. Random Early Detection (RED) • Notification is implicit • just drop the packet (TCP will timeout) • could make explicit by marking the packet • Early random drop • rather than wait for queue to become full, drop each arriving packet with some drop probability whenever the queue length exceeds some drop level CSE30264

  18. RED Details • Compute average queue length AvgLen = (1 - Weight) * AvgLen + Weight * SampleLen 0 < Weight < 1 (usually 0.002) SampleLen is queue length each time a packet arrives CSE30264

  19. RED Details (cont) • Two queue length thresholds if AvgLen <= MinThreshold then enqueue the packet if MinThreshold < AvgLen < MaxThreshold then calculate probability P drop arriving packet with probability P if MaxThreshold <= AvgLen then drop arriving packet CSE30264

  20. RED Details (cont) • Computing probability P TempP = MaxP * (AvgLen - MinThreshold)/ (MaxThreshold - MinThreshold) P = TempP/(1 - count * TempP) • Drop Probability Curve CSE30264

  21. Tuning RED • Probability of dropping a particular flow’s packet(s) is roughly proportional to the share of the bandwidth that flow is currently getting • MaxP is typically set to 0.02, meaning that when the average queue size is halfway between the two thresholds, the gateway drops roughly one out of 50 packets. • If traffic is bursty, then MinThreshold should be sufficiently large to allow link utilization to be maintained at an acceptably high level • Difference between two thresholds should be larger than the typical increase in the calculated average queue length in one RTT; setting MaxThreshold to twice MinThreshold is reasonable for traffic on today’s Internet CSE30264

  22. TCP Vegas • Idea: source watches for some sign that router’s queue is building up and congestion will happen too; e.g., • RTT grows • sending rate flattens CSE30264

  23. Algorithm • Let BaseRTT be the minimum of all measured RTTs (commonly the RTT of the first packet) • If not overflowing the connection, then ExpectedRate = CongestionWindow/BaseRTT • Source calculates sending rate (ActualRate) once per RTT • Source compares ActualRate with ExpectedRate Diff = ExpectedRate - ActualRate if Diff < a increase CongestionWindow linearly else if Diff > b decrease CongestionWindow linearly else leave CongestionWindow unchanged CSE30264

  24. Algorithm (cont) • Parameters • a = 1 packet • b = 3 packets CSE30264

More Related