10/7/2003-10/9/2003

TCP and Congestion Control

October 7-9, 2003

10/7/2003-10/9/2003

Assignments

• Finish chapter 3

• Finish up your project!

10/7/2003-10/9/2003

TCP: Overview

• Point-to-Point– one sender, one receiver

• Connection-oriented– handshaking (exchange of control msgs)

• Reliable, in order data delivery• Pipelined• Full duplex data• Flow controlled

– sender will not overwhelm receiver

10/7/2003-10/9/2003

TCP Examplesocketdoor

T C Psend buffer

T C Preceive buffer

socketdoor

segm en t

applica tionwrites data

applica tionreads data

• Application data placed in send buffer• Data taken from send buffer and placed in

segment (data + header)– Max amount of data is MSS

• Data placed in receive buffer• App reads from receiver buffer• Applet

10/7/2003-10/9/2003

TCP Segment Structure

source port # dest port #

32 bits

applicationdata

(variable length)

sequence number

acknowledgement numberReceive window

Urg data pnterchecksum

FSRPAUheadlen

notused

Options (variable length)

URG: urgent data (generally not used)

ACK: ACK #valid

PSH: push data now(generally not used)

RST, SYN, FIN:connection estab(setup, teardown

commands)

# bytes rcvr willingto accept

countingby bytes of data(not segments!)

Internetchecksum

(as in UDP)

10/7/2003-10/9/2003

Seq #’s and ACKs

• Seq #’s– Byte stream “number”

of first byte in segment’s data

– First is randomly chosen

• ACKs– Seq # of next byte

expected from other side

– Cumulative ACK– Piggybacking

Host A Host B

Seq=42, ACK=79, data = ‘C’

Seq=79, ACK=43, data = ‘C’

Seq=43, ACK=80

Usertypes

‘C’

host ACKsreceipt

of echoed‘C’

host ACKsreceipt of

‘C’, echoesback ‘C’

timesimple telnet scenario

10/7/2003-10/9/2003

Round Trip Time and Timeout

• TCP uses timeout mechanism

• How can we determine the timeout value?– Must be longer than RTT– Too short?– Too long?

• Take SampleRTT – but RTT varies

10/7/2003-10/9/2003

Round Trip Time and TimeoutEstimatedRTT = (1- )*EstimatedRTT + *SampleRTT

• Exponential weighted moving average• Influence of past sample decreases exponentially fast• Typical value: = 0.125

10/7/2003-10/9/2003

Example RTT EstimationRTT: gaia.cs.umass.edu to fantasia.eurecom.fr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

10/7/2003-10/9/2003

Round Trip Time and Timeout

• Timeout also takes into account how much the EstimatedRTT deviates from the SampleRTT

TimeoutInterval = EstimatedRTT + 4*DevRTT

10/7/2003-10/9/2003

TCP Reliable Data Transfer

• TCP creates rdt service on top of IP’s unreliable service– Reliable, in order delivery

• Pipelined segments• Cumulative acks• TCP uses single retransmission timer

– Retransmit triggered by timeout and duplicate ACK

• Consider simplified design– No duplicate ACKs, flow control, or congestion control

10/7/2003-10/9/2003

TCP Sender Events• Data received from app

– Create segment with seq #– seq # is byte-stream number of first data byte in segment– Start timer if not already running (think of timer as for oldest

unacked segment)– Expiration interval: TimeOutInterval

• Timeout– Retransmit segment that caused timeout– Restart timer

• Ack rcvd– If acknowledges previously unacked segments

• update what is known to be acked• start timer if there are outstanding segments

10/7/2003-10/9/2003

Retransmit ScenariosHost A

Seq=100, 20 bytes data

ACK=100

timepremature timeout

Host B

Seq=92, 8 bytes data

ACK=120

Seq=92, 8 bytes data

Seq=

92

tim

eout

ACK=120

Host A

Seq=92, 8 bytes data

ACK=100

loss

tim

eout

lost ACK scenario

Host B

X

Seq=92, 8 bytes data

ACK=100

timeSeq=

92

tim

eout

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

10/7/2003-10/9/2003

Retransmit ScenariosHost A

Seq=92, 8 bytes data

ACK=100

loss

tim

eout

Cumulative ACK scenario

Host B

X

Seq=100, 20 bytes data

ACK=120

time

SendBase= 120

10/7/2003-10/9/2003

TCP ACK Generation

Event at Receiver

Arrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKed

Arrival of in-order segment withexpected seq #. One other segment has ACK pending

Arrival of out-of-order segmenthigher-than-expect seq. # .Gap detected

Arrival of segment that partially or completely fills gap

TCP Receiver action

Delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK

Immediately send single cumulative ACK, ACKing both in-order segments

Immediately send duplicate ACK, indicating seq. # of next expected byte

Immediate send ACK, provided thatsegment starts at lower end of gap

10/7/2003-10/9/2003

Fast Retransmit

• Time-out period often relatively long– long delay before resending lost packet

• Detect lost segments via duplicate ACKs– Sender often sends many segments back-to-back– If segment is lost, there will likely be many duplicate

ACKs

• If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost– fast retransmit: resend segment before timer expires

10/7/2003-10/9/2003

TCP Flow Control

• Need to keep sender from sending too fast for receiver

• Match sending rate with receiver “drain” rate

10/7/2003-10/9/2003

Operation

RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead]

• Rcvr advertises spare room by including value of RcvWindow in segments

• Sender limits unACKed data to RcvWindow– guarantees receive buffer doesn’t overflow

• Sender actually continues to send 1-byte pkts after receiver window is full – WHY?

10/7/2003-10/9/2003

TCP Connection Management

• Sender and receiver establish “connection” before exchanging data segments

• Initialize TCP variables– seq. #s– buffers, flow control info (e.g. RcvWindow)

• Client initiates connection– Socket clientSocket = new Socket("hostname","port

number");

• Server accepts connection– Socket connectionSocket = welcomeSocket.accept();

10/7/2003-10/9/2003

TCP Connection Management

• Three way handshake– Step 1: client host sends TCP SYN segment to server

• specifies initial seq #• no data

– Step 2: server host receives SYN, replies with SYNACK segment

• server allocates buffers• specifies server initial seq. #

– Step 3: client receives SYNACK, replies with ACK segment, which may contain data

10/7/2003-10/9/2003

Three-way Handshake

client

SYN=1, seq=12345

server

SYN=1, seq=98765, ack=12346

SYN=0, seq=12346, ack=98766

ConnectionRequest

ConnectionGranted

ACK

10/7/2003-10/9/2003

TCP Connection Management

• Closing a connection– client closes socket: clientSocket.close(); – Step 1: client end system sends TCP FIN control

segment to server – Step 2: server receives FIN, replies with ACK. Closes

connection, sends FIN. – Step 3: client receives FIN, replies with ACK. – Enters “timed wait” - will respond with ACK to

received FINs – Step 4: server, receives ACK. Connection closed.

10/7/2003-10/9/2003

Teardown

client

FIN

server

ACK

ACK

FIN

close

close

closed

tim

ed w

ait

10/7/2003-10/9/2003

Principles of 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)

10/7/2003-10/9/2003

Scenario 1: Queuing Delays • two senders, two

receivers• one router, infinite

buffers • no retransmission

• large delays when congested

• maximum achievable throughput

unlimited shared output link buffers

Host Ain : original data

Host B

out

10/7/2003-10/9/2003

Scenario 2: Retransmits • One router, finite buffers • Sender retransmission of lost packet

– Original packet dropped– Original packet delayed

finite shared output link buffers

Host A in : original data

Host B

out

'in : original data, plus retransmitted data

10/7/2003-10/9/2003

Scenario 3: Congestion Near Receiver

• four senders• multihop paths• timeout/retransmit

finite shared output link buffers

Host Ain : original data

Host B

out

'in : original data, plus retransmitted data

10/7/2003-10/9/2003

Approaches

• End-end congestion control– no explicit feedback

from network– congestion inferred

from end-system observed loss, delay

– approach taken by TCP

• Network-assisted congestion control– routers provide

feedback to end systems

• single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM)

• explicit rate sender should send at

10/7/2003-10/9/2003

TCP Congestion Control

• End-end control (no network assistance)

• Sender limits transmission

LastByteSent-LastByteAcked CongWin

• CongWin is dynamic, function of perceived network congestion

• Different than the RcvWindow

10/7/2003-10/9/2003

TCP Congestion Control

• How does sender perceive congestion?– loss event = timeout or 3 duplicate acks– Is this always a good measure?– TCP sender reduces rate (CongWin) after

loss event

• Three components of CC algorithm– AIMD– slow start– conservative after timeout events

10/7/2003-10/9/2003

TCP AIMD – Congestion Avoidance

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

• Multiplicative Decrease – cut CongWin in half

after loss event

• Additive Increase– increase CongWin by 1 MSS

every RTT in the absence of loss events: probing

Long-lived TCP connection

10/7/2003-10/9/2003

TCP Slow Start

• When connection begins, CongWin = 1 MSS– Example: MSS = 500 bytes & RTT = 200 msec– initial rate = 20 kbps

• Available bandwidth may be >> MSS/RTT– desirable to quickly ramp up to respectable rate

• When connection begins, increase rate exponentially fast until first loss event– Double CongWin every RTT until a loss – After loss – reduce CongWin by ½ and increase

linerarly

10/7/2003-10/9/2003

Slow Start Example

• Double CongWin every RTT– done by incrementing CongWin for every ACK received

Host A

one segment

RTT

Host B

time

two segments

four segments

10/7/2003-10/9/2003

Timeout Events

• After 3 dup ACKs– CongWin is cut in half– window then grows linearly

• But, after timeout event– CongWin instead set to 1 MSS– window then grows exponentially to a threshold (1/2

previous CongWin size), then grows linearly

• Idea – 3 dup ACKs indicates network capable of delivering some segments– timeout before 3 dup ACKs is “more alarming”

10/7/2003-10/9/2003

Threshold

• Threshold– Starts at 65K– Set to ½ CongWin

when loss event occurs

• TCP Tahoe vs TCP Reno 0

2

4

6

8

10

12

14

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Transmission round

co

ng

es

tio

n w

ind

ow

siz

e

(se

gm

en

ts)

Series1 Series2

10/7/2003-10/9/2003

Summary: TCP Congestion Control

• 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