1

Lecture 9:

TCP and Congestion Control

Slides adapted from:Congestion slides for Computer Networks: A Systems Approach (Peterson and Davis)

Chapter 3 slides for Computer Networking: A Top Down Approach Featuring the Internet (Kurose and Ross)

ITCS 6166/8166 091Spring 2007

Jamie PaytonDepartment of Computer Science

University of North Carolina at Charlotte

February 7, 2007

2

Announcements

• Homework 2 is available– Due: Feb. 14

• Schedule change– Updated on primary course website

• Additional homework before midterm• Lab 1 due date changed

3

Transmission Control Protocol

• Implementation of sliding window protocol

TCP Segment (Packet) Structure

TCP uses sliding windows at sender and receiver

(buffers)

4

Flow Control

• What happens if the receiving process is slow and the sending process is fast?

• TCP provides flow control– sender won’t overflow receiver’s buffer by

transmitting too much, too fast

5

Window “Syndromes”

• Silly Window Syndrome– Sender has data available to send– Flow control reduces effective window to very small

size• Size of segment dominated by the header information

• Tinygram Syndrome– Sender doesn’t have much data to send

• Size of segment dominated by the header information

– Nagle’s algorithm combats this problem• Coalesces small messages into a single segment if some

data is currently unack’d

6

Congestion Control

Congestion:• Informally: “too many sources sending too much

data too fast for network to handle”• Different from flow control!• Manifestations:

– lost packets (buffer overflow at routers)– long delays (queueing in router buffers)

• A top-10 problem in computer network research!

7

TCP Congestion Control

• Idea– assumes best-effort network (FIFO or FQ routers)– each source determines network capacity for itself– uses implicit feedback– ACKs pace transmission (self-clocking)

• Challenges– determining the available capacity in the first place– adjusting to changes in the available capacity

8

TCP Congestion Control Principles

• Simple idea– Congestion: reduce sending rate– No congestion: increase sending rate

• How does the source determine whether or not the network is congested?– Lost packets!

• Timeout signals that a packet was lost• Duplicate acknowledgements signal packet was lost (later...)

• How is rate controlled in TCP?– Control congestion window size– Rate approximately congestion window size / RTT

9

TCP Congestion Control Components

• Additive Increase/Multiplicative Decrease

• Slow start

• Fast Retransmit and Fast Recovery

10

Additive Increase Multiplicative Decrease

• New state variable per connection: CongWin– Counterpart to flow control’s advertised window– Limits how much data is in transit

MaxWin = MIN(CongWin, AdvertisedWindow)

EffWin = MaxWin - (LastByteSent - LastByteAcked)

• Congestion control approach:– increase CongWin when congestion goes down– decrease CongWin when congestion goes up

• Now EffectiveWindow includes both flow control and congestion control

11

Additive Increase Multiplicative Decrease

• Approach:– increase transmission rate,

probing for usable bandwidth, until loss occurs

– additive increase: increase CongWin by 1 MSS every RTT until loss detected

– multiplicative decrease: cut CongWin in half after loss

Host A

one segment

RTT

Host B

time

two segments

Three segments

12

Slow Start

• Objective: determine the available capacity at first– increase congestion window rapidly

from a cold start

• Idea:– begin with CongWin = 1 packet– double CongWin each RTT

• Implemented : increment by 1 packet for each ACK

Host A

one segment

RTT

Host B

time

two segments

four segments

13

Refinement 1

Q: When should the exponential increase switch to linear?

A: When CongWin gets to 1/2 of its value before timeout.

Implementation:• Variable Threshold • At loss event, Threshold is set to 1/2 of CongWin

just before loss event– Initially set to large value

14

Refinement 2

• Fast recovery– skip the slow start phase– go directly to threshold

• half the last successful CongWin

• Philosophy– Duplicate ACKs also indicate loss

– 3 duplicate ACKs indicates network capable of delivering some segments

– Timeout indicates a “more alarming” congestion scenario

15

TCP Flavors• TCP Tahoe

– Slow start • Switch to AIMD when hit threshold

– Handling loss• Unconditional reduction of window to 1 MSS

• TCP Reno– Slow start

• Switch to AIMD when hit threshold

– Handling loss• Reduction of window to ½

when triple duplicate ACKS• “Fast recovery”: skip slow

start, go to threshold

16

Summary: TCP Reno

• When CongWin is below Threshold, sender in slow-start phase, window grows exponentially.

• When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly.

• When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold.

• When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS