CSE 30264 Computer Networks

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