CSE 30264
Computer Networks
Prof. Aaron StriegelDepartment of Computer Science & Engineering
University of Notre Dame
Lecture 19 – March 23, 2010
CSE 30264 2
Today’s Lecture
• Project 2– Q&A
• Project 3– Overview
• Transport– TCP Congestion
Control
Spring 2010
Physical
Data
Network
Transport
Application
CSE 30264 3
Project 2
• Last questions?
Spring 2010
CSE 30264 4
Project 3
• Flex your network socket muscles• Peer to peer system
– Search / share binary files• Two components
– Client– Tracker
Spring 2010
Due: Tuesday, April 13 @ 5 PM
CSE 30264 5
Project 3
• Operational order– Client starts up
• irishP2P ServerIP ServerPort MaxPeers– 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
Spring 2010
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
Spring 2010
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
Spring 2010
CSE 30264 8
Project 3 - Search
• Simple search dynamics– Search only immediate peers– Look only at file name
• Assume file name is descriptive
Spring 2010
> search *Peas*.mp3Searching 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
Spring 2010
> 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
Spring 2010
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
Spring 2010
Spring 2009 CSE30264 12
Congestion Control
OutlineCongestion AvoidanceREDTCP Vegas
Spring 2009 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
Spring 2009 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
Spring 2009 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
CSE 30264 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?
Spring 2010
Are there any problems with it?
Spring 2009 CSE30264 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
Spring 2009 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
Spring 2009 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
Spring 2009 CSE30264 20
RED Details (cont)• Computing probability P
TempP = MaxP * (AvgLen - MinThreshold)/ (MaxThreshold - MinThreshold)
P = TempP/(1 - count * TempP)
• Drop Probability Curve
Spring 2009 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
Spring 2009 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
Spring 2009 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 - ActualRateif Diff < a
increase CongestionWindow linearlyelse if Diff > b
decrease CongestionWindow linearlyelse
leave CongestionWindow unchanged
Spring 2009 CSE30264 24
Algorithm (cont)• Parameters
- a = 1 packet- b = 3 packets