1 lecture 9: tcp and congestion control slides adapted from: congestion slides for computer...
Post on 20-Dec-2015
214 views
TRANSCRIPT
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