Ch3-2 -1

Chapter 3 outline

Transport-layer services

Principles of reliable data transfer

Connectionless transport UDP

(self ndashstudy assignment)

35 Connection-oriented transport TCP

36 Principles of congestion control

37 TCP congestion control

Summary

Ch3-2 -2

TCP Overview RFCs 793 1122 1323 2018 2581

Pipelined with send amp receive buffers

flow controlled sender will not

overwhelm receiver Congestion control

Sender sets its window size for congestion control (and flow control)

pt-to-pt (ie no multicast one sender one

receiver full duplex data

bi-directional data flow in same connection

MSS maximum segment size

connection-oriented handshaking (exchange

of control msgs) initrsquos sender amp receiver states before data exchange

reliable in-order byte steam no ldquomessage

boundariesrdquo

socketdoor

T C Psend buffer

T C Preceive buffer

socketdoor

segm ent

applicationwrites data

applicationreads data

Ch3-2 -3

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 FINconnection estab(setup teardown

commands)

bytes rcvr willingto accept

representedby bytes of data

Internetchecksum

(as in UDP)

Ch3-2 -4

TCP seq rsquos and ACKsSeq rsquos

byte stream ldquonumberrdquo of first byte in segmentrsquos data

ACKs seq of next byte

expected from other side

cumulative ACKQ how receiver handles

out-of-order segments A TCP spec doesnrsquot

say - up to implementor

Host A Host B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

Usertypes

lsquoCrsquo

host ACKsreceipt

of echoedlsquoCrsquo

host ACKsreceipt of

lsquoCrsquo echoesback lsquoCrsquo

timesimple telnet scenario

Ch3-2 -5

TCP retransmission scenarios

Host A

Seq=100 20 bytes data

ACK=100

timepremature timeout(Accumulative ACK)

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

time

Seq=

92

tim

eout

Expected (or

NextBytetoSend = 100Expected

(orNextBytetoSend = 120

Expected (or

NextBytetoSend = 120

Expected (or

NextBytetoSend = 100

Ch3-2 -6

TCP Round Trip Time and TimeoutQ how to set TCP

timeout value longer than RTT

but RTT varies too short premature

timeout unnecessary

retransmissions too long slow

reaction to segment loss

Q how to estimate RTT SampleRTT measured time

from segment transmission until ACK receipt ignore retransmissions

SampleRTT will vary want estimated RTT ldquosmootherrdquo average several recent

measurements not just current SampleRTT

Ch3-2 -7

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

Exponential weighted moving average influence of past sample decreases exponentially fast typical value = 0125

Ch3-2 -8

Example RTT estimationRTT gaiacsumassedu to fantasiaeurecomfr

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

Ch3-2 -9

TCP Round Trip Time and TimeoutSetting the timeout EstimtedRTT plus ldquosafety marginrdquo

large variation in EstimatedRTT -gt larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

(typically = 025)

Then set timeout interval

Ch3-2 -10

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

Transport Layer 3-11

Host A

tim

eout

Host B

time

X

resend seq X2

seq x1seq x2seq x3seq x4seq x5

ACK x1

ACK x1ACK x1ACK x1

tripleduplicate

ACKs

Ch3-2 -12

event ACK received with ACK field value of y if (y gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer else increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) resend segment with sequence number y

Fast retransmit algorithm

a duplicate ACK for already ACKed segment

fast retransmit

Ch3-2 -13

TCP Flow Control

receive side of TCP connection has a receive buffer

speed-matching service matching the send rate to the receiving apprsquos drain rate app process may be

slow at reading from buffer

sender wonrsquot overflow

receiverrsquos buffer bytransmitting too

much too fast

flow control

Ch3-2 -14

TCP Flow control how it works

(Suppose TCP receiver discards out-of-order segments)

spare room in buffer= RcvWindow ( = rwnd)

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesnrsquot overflow The number of unACKed

data will be the smaller of RcvWindow and Congestion Window (to be discussed later)

Ch3-2 -15

TCP Connection Management

Recall TCP sender receiver establish ldquoconnectionrdquo before exchanging data segments

initialize TCP variables seq s buffers flow control info

(eg RcvWindow) client connection initiator Socket clientSocket = new

Socket(hostnameport

number) server contacted by client Socket connectionSocket =

welcomeSocketaccept()

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

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -2

TCP Overview RFCs 793 1122 1323 2018 2581

Pipelined with send amp receive buffers

flow controlled sender will not

overwhelm receiver Congestion control

Sender sets its window size for congestion control (and flow control)

pt-to-pt (ie no multicast one sender one

receiver full duplex data

bi-directional data flow in same connection

MSS maximum segment size

connection-oriented handshaking (exchange

of control msgs) initrsquos sender amp receiver states before data exchange

reliable in-order byte steam no ldquomessage

boundariesrdquo

socketdoor

T C Psend buffer

T C Preceive buffer

socketdoor

segm ent

applicationwrites data

applicationreads data

Ch3-2 -3

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 FINconnection estab(setup teardown

commands)

bytes rcvr willingto accept

representedby bytes of data

Internetchecksum

(as in UDP)

Ch3-2 -4

TCP seq rsquos and ACKsSeq rsquos

byte stream ldquonumberrdquo of first byte in segmentrsquos data

ACKs seq of next byte

expected from other side

cumulative ACKQ how receiver handles

out-of-order segments A TCP spec doesnrsquot

say - up to implementor

Host A Host B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

Usertypes

lsquoCrsquo

host ACKsreceipt

of echoedlsquoCrsquo

host ACKsreceipt of

lsquoCrsquo echoesback lsquoCrsquo

timesimple telnet scenario

Ch3-2 -5

TCP retransmission scenarios

Host A

Seq=100 20 bytes data

ACK=100

timepremature timeout(Accumulative ACK)

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

time

Seq=

92

tim

eout

Expected (or

NextBytetoSend = 100Expected

(orNextBytetoSend = 120

Expected (or

NextBytetoSend = 120

Expected (or

NextBytetoSend = 100

Ch3-2 -6

TCP Round Trip Time and TimeoutQ how to set TCP

timeout value longer than RTT

but RTT varies too short premature

timeout unnecessary

retransmissions too long slow

reaction to segment loss

Q how to estimate RTT SampleRTT measured time

from segment transmission until ACK receipt ignore retransmissions

SampleRTT will vary want estimated RTT ldquosmootherrdquo average several recent

measurements not just current SampleRTT

Ch3-2 -7

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

Exponential weighted moving average influence of past sample decreases exponentially fast typical value = 0125

Ch3-2 -8

Example RTT estimationRTT gaiacsumassedu to fantasiaeurecomfr

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

Ch3-2 -9

TCP Round Trip Time and TimeoutSetting the timeout EstimtedRTT plus ldquosafety marginrdquo

large variation in EstimatedRTT -gt larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

(typically = 025)

Then set timeout interval

Ch3-2 -10

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

Transport Layer 3-11

Host A

tim

eout

Host B

time

X

resend seq X2

seq x1seq x2seq x3seq x4seq x5

ACK x1

ACK x1ACK x1ACK x1

tripleduplicate

ACKs

Ch3-2 -12

event ACK received with ACK field value of y if (y gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer else increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) resend segment with sequence number y

Fast retransmit algorithm

a duplicate ACK for already ACKed segment

fast retransmit

Ch3-2 -13

TCP Flow Control

receive side of TCP connection has a receive buffer

speed-matching service matching the send rate to the receiving apprsquos drain rate app process may be

slow at reading from buffer

sender wonrsquot overflow

receiverrsquos buffer bytransmitting too

much too fast

flow control

Ch3-2 -14

TCP Flow control how it works

(Suppose TCP receiver discards out-of-order segments)

spare room in buffer= RcvWindow ( = rwnd)

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesnrsquot overflow The number of unACKed

data will be the smaller of RcvWindow and Congestion Window (to be discussed later)

Ch3-2 -15

TCP Connection Management

Recall TCP sender receiver establish ldquoconnectionrdquo before exchanging data segments

initialize TCP variables seq s buffers flow control info

(eg RcvWindow) client connection initiator Socket clientSocket = new

Socket(hostnameport

number) server contacted by client Socket connectionSocket =

welcomeSocketaccept()

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

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -3

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 FINconnection estab(setup teardown

commands)

bytes rcvr willingto accept

representedby bytes of data

Internetchecksum

(as in UDP)

Ch3-2 -4

TCP seq rsquos and ACKsSeq rsquos

byte stream ldquonumberrdquo of first byte in segmentrsquos data

ACKs seq of next byte

expected from other side

cumulative ACKQ how receiver handles

out-of-order segments A TCP spec doesnrsquot

say - up to implementor

Host A Host B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

Usertypes

lsquoCrsquo

host ACKsreceipt

of echoedlsquoCrsquo

host ACKsreceipt of

lsquoCrsquo echoesback lsquoCrsquo

timesimple telnet scenario

Ch3-2 -5

TCP retransmission scenarios

Host A

Seq=100 20 bytes data

ACK=100

timepremature timeout(Accumulative ACK)

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

time

Seq=

92

tim

eout

Expected (or

NextBytetoSend = 100Expected

(orNextBytetoSend = 120

Expected (or

NextBytetoSend = 120

Expected (or

NextBytetoSend = 100

Ch3-2 -6

TCP Round Trip Time and TimeoutQ how to set TCP

timeout value longer than RTT

but RTT varies too short premature

timeout unnecessary

retransmissions too long slow

reaction to segment loss

Q how to estimate RTT SampleRTT measured time

from segment transmission until ACK receipt ignore retransmissions

SampleRTT will vary want estimated RTT ldquosmootherrdquo average several recent

measurements not just current SampleRTT

Ch3-2 -7

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

Exponential weighted moving average influence of past sample decreases exponentially fast typical value = 0125

Ch3-2 -8

Example RTT estimationRTT gaiacsumassedu to fantasiaeurecomfr

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

Ch3-2 -9

TCP Round Trip Time and TimeoutSetting the timeout EstimtedRTT plus ldquosafety marginrdquo

large variation in EstimatedRTT -gt larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

(typically = 025)

Then set timeout interval

Ch3-2 -10

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

Transport Layer 3-11

Host A

tim

eout

Host B

time

X

resend seq X2

seq x1seq x2seq x3seq x4seq x5

ACK x1

ACK x1ACK x1ACK x1

tripleduplicate

ACKs

Ch3-2 -12

event ACK received with ACK field value of y if (y gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer else increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) resend segment with sequence number y

Fast retransmit algorithm

a duplicate ACK for already ACKed segment

fast retransmit

Ch3-2 -13

TCP Flow Control

receive side of TCP connection has a receive buffer

speed-matching service matching the send rate to the receiving apprsquos drain rate app process may be

slow at reading from buffer

sender wonrsquot overflow

receiverrsquos buffer bytransmitting too

much too fast

flow control

Ch3-2 -14

TCP Flow control how it works

(Suppose TCP receiver discards out-of-order segments)

spare room in buffer= RcvWindow ( = rwnd)

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesnrsquot overflow The number of unACKed

data will be the smaller of RcvWindow and Congestion Window (to be discussed later)

Ch3-2 -15

TCP Connection Management

Recall TCP sender receiver establish ldquoconnectionrdquo before exchanging data segments

initialize TCP variables seq s buffers flow control info

(eg RcvWindow) client connection initiator Socket clientSocket = new

Socket(hostnameport

number) server contacted by client Socket connectionSocket =

welcomeSocketaccept()

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

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -4

TCP seq rsquos and ACKsSeq rsquos

byte stream ldquonumberrdquo of first byte in segmentrsquos data

ACKs seq of next byte

expected from other side

cumulative ACKQ how receiver handles

out-of-order segments A TCP spec doesnrsquot

say - up to implementor

Host A Host B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

Usertypes

lsquoCrsquo

host ACKsreceipt

of echoedlsquoCrsquo

host ACKsreceipt of

lsquoCrsquo echoesback lsquoCrsquo

timesimple telnet scenario

Ch3-2 -5

TCP retransmission scenarios

Host A

Seq=100 20 bytes data

ACK=100

timepremature timeout(Accumulative ACK)

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

time

Seq=

92

tim

eout

Expected (or

NextBytetoSend = 100Expected

(orNextBytetoSend = 120

Expected (or

NextBytetoSend = 120

Expected (or

NextBytetoSend = 100

Ch3-2 -6

TCP Round Trip Time and TimeoutQ how to set TCP

timeout value longer than RTT

but RTT varies too short premature

timeout unnecessary

retransmissions too long slow

reaction to segment loss

Q how to estimate RTT SampleRTT measured time

from segment transmission until ACK receipt ignore retransmissions

SampleRTT will vary want estimated RTT ldquosmootherrdquo average several recent

measurements not just current SampleRTT

Ch3-2 -7

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

Exponential weighted moving average influence of past sample decreases exponentially fast typical value = 0125

Ch3-2 -8

Example RTT estimationRTT gaiacsumassedu to fantasiaeurecomfr

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

Ch3-2 -9

TCP Round Trip Time and TimeoutSetting the timeout EstimtedRTT plus ldquosafety marginrdquo

large variation in EstimatedRTT -gt larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

(typically = 025)

Then set timeout interval

Ch3-2 -10

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

Transport Layer 3-11

Host A

tim

eout

Host B

time

X

resend seq X2

seq x1seq x2seq x3seq x4seq x5

ACK x1

ACK x1ACK x1ACK x1

tripleduplicate

ACKs

Ch3-2 -12

event ACK received with ACK field value of y if (y gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer else increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) resend segment with sequence number y

Fast retransmit algorithm

a duplicate ACK for already ACKed segment

fast retransmit

Ch3-2 -13

TCP Flow Control

receive side of TCP connection has a receive buffer

speed-matching service matching the send rate to the receiving apprsquos drain rate app process may be

slow at reading from buffer

sender wonrsquot overflow

receiverrsquos buffer bytransmitting too

much too fast

flow control

Ch3-2 -14

TCP Flow control how it works

(Suppose TCP receiver discards out-of-order segments)

spare room in buffer= RcvWindow ( = rwnd)

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesnrsquot overflow The number of unACKed

data will be the smaller of RcvWindow and Congestion Window (to be discussed later)

Ch3-2 -15

TCP Connection Management

Recall TCP sender receiver establish ldquoconnectionrdquo before exchanging data segments

initialize TCP variables seq s buffers flow control info

(eg RcvWindow) client connection initiator Socket clientSocket = new

Socket(hostnameport

number) server contacted by client Socket connectionSocket =

welcomeSocketaccept()

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

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -5

TCP retransmission scenarios

Host A

Seq=100 20 bytes data

ACK=100

timepremature timeout(Accumulative ACK)

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

time

Seq=

92

tim

eout

Expected (or

NextBytetoSend = 100Expected

(orNextBytetoSend = 120

Expected (or

NextBytetoSend = 120

Expected (or

NextBytetoSend = 100

Ch3-2 -6

TCP Round Trip Time and TimeoutQ how to set TCP

timeout value longer than RTT

but RTT varies too short premature

timeout unnecessary

retransmissions too long slow

reaction to segment loss

Q how to estimate RTT SampleRTT measured time

from segment transmission until ACK receipt ignore retransmissions

SampleRTT will vary want estimated RTT ldquosmootherrdquo average several recent

measurements not just current SampleRTT

Ch3-2 -7

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

Exponential weighted moving average influence of past sample decreases exponentially fast typical value = 0125

Ch3-2 -8

Example RTT estimationRTT gaiacsumassedu to fantasiaeurecomfr

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

Ch3-2 -9

TCP Round Trip Time and TimeoutSetting the timeout EstimtedRTT plus ldquosafety marginrdquo

large variation in EstimatedRTT -gt larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

(typically = 025)

Then set timeout interval

Ch3-2 -10

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

Transport Layer 3-11

Host A

tim

eout

Host B

time

X

resend seq X2

seq x1seq x2seq x3seq x4seq x5

ACK x1

ACK x1ACK x1ACK x1

tripleduplicate

ACKs

Ch3-2 -12

event ACK received with ACK field value of y if (y gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer else increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) resend segment with sequence number y

Fast retransmit algorithm

a duplicate ACK for already ACKed segment

fast retransmit

Ch3-2 -13

TCP Flow Control

receive side of TCP connection has a receive buffer

speed-matching service matching the send rate to the receiving apprsquos drain rate app process may be

slow at reading from buffer

sender wonrsquot overflow

receiverrsquos buffer bytransmitting too

much too fast

flow control

Ch3-2 -14

TCP Flow control how it works

(Suppose TCP receiver discards out-of-order segments)

spare room in buffer= RcvWindow ( = rwnd)

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesnrsquot overflow The number of unACKed

data will be the smaller of RcvWindow and Congestion Window (to be discussed later)

Ch3-2 -15

TCP Connection Management

Recall TCP sender receiver establish ldquoconnectionrdquo before exchanging data segments

initialize TCP variables seq s buffers flow control info

(eg RcvWindow) client connection initiator Socket clientSocket = new

Socket(hostnameport

number) server contacted by client Socket connectionSocket =

welcomeSocketaccept()

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

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -6

TCP Round Trip Time and TimeoutQ how to set TCP

timeout value longer than RTT

but RTT varies too short premature

timeout unnecessary

retransmissions too long slow

reaction to segment loss

Q how to estimate RTT SampleRTT measured time

from segment transmission until ACK receipt ignore retransmissions

SampleRTT will vary want estimated RTT ldquosmootherrdquo average several recent

measurements not just current SampleRTT

Ch3-2 -7

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

Exponential weighted moving average influence of past sample decreases exponentially fast typical value = 0125

Ch3-2 -8

Example RTT estimationRTT gaiacsumassedu to fantasiaeurecomfr

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

Ch3-2 -9

TCP Round Trip Time and TimeoutSetting the timeout EstimtedRTT plus ldquosafety marginrdquo

large variation in EstimatedRTT -gt larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

(typically = 025)

Then set timeout interval

Ch3-2 -10

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

Transport Layer 3-11

Host A

tim

eout

Host B

time

X

resend seq X2

seq x1seq x2seq x3seq x4seq x5

ACK x1

ACK x1ACK x1ACK x1

tripleduplicate

ACKs

Ch3-2 -12

event ACK received with ACK field value of y if (y gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer else increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) resend segment with sequence number y

Fast retransmit algorithm

a duplicate ACK for already ACKed segment

fast retransmit

Ch3-2 -13

TCP Flow Control

receive side of TCP connection has a receive buffer

speed-matching service matching the send rate to the receiving apprsquos drain rate app process may be

slow at reading from buffer

sender wonrsquot overflow

receiverrsquos buffer bytransmitting too

much too fast

flow control

Ch3-2 -14

TCP Flow control how it works

(Suppose TCP receiver discards out-of-order segments)

spare room in buffer= RcvWindow ( = rwnd)

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesnrsquot overflow The number of unACKed

data will be the smaller of RcvWindow and Congestion Window (to be discussed later)

Ch3-2 -15

TCP Connection Management

Recall TCP sender receiver establish ldquoconnectionrdquo before exchanging data segments

initialize TCP variables seq s buffers flow control info

(eg RcvWindow) client connection initiator Socket clientSocket = new

Socket(hostnameport

number) server contacted by client Socket connectionSocket =

welcomeSocketaccept()

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

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -7

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

Exponential weighted moving average influence of past sample decreases exponentially fast typical value = 0125

Ch3-2 -8

Example RTT estimationRTT gaiacsumassedu to fantasiaeurecomfr

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

Ch3-2 -9

TCP Round Trip Time and TimeoutSetting the timeout EstimtedRTT plus ldquosafety marginrdquo

large variation in EstimatedRTT -gt larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

(typically = 025)

Then set timeout interval

Ch3-2 -10

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

Transport Layer 3-11

Host A

tim

eout

Host B

time

X

resend seq X2

seq x1seq x2seq x3seq x4seq x5

ACK x1

ACK x1ACK x1ACK x1

tripleduplicate

ACKs

Ch3-2 -12

event ACK received with ACK field value of y if (y gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer else increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) resend segment with sequence number y

Fast retransmit algorithm

a duplicate ACK for already ACKed segment

fast retransmit

Ch3-2 -13

TCP Flow Control

receive side of TCP connection has a receive buffer

speed-matching service matching the send rate to the receiving apprsquos drain rate app process may be

slow at reading from buffer

sender wonrsquot overflow

receiverrsquos buffer bytransmitting too

much too fast

flow control

Ch3-2 -14

TCP Flow control how it works

(Suppose TCP receiver discards out-of-order segments)

spare room in buffer= RcvWindow ( = rwnd)

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesnrsquot overflow The number of unACKed

data will be the smaller of RcvWindow and Congestion Window (to be discussed later)

Ch3-2 -15

TCP Connection Management

Recall TCP sender receiver establish ldquoconnectionrdquo before exchanging data segments

initialize TCP variables seq s buffers flow control info

(eg RcvWindow) client connection initiator Socket clientSocket = new

Socket(hostnameport

number) server contacted by client Socket connectionSocket =

welcomeSocketaccept()

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

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -8

Example RTT estimationRTT gaiacsumassedu to fantasiaeurecomfr

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

Ch3-2 -9

TCP Round Trip Time and TimeoutSetting the timeout EstimtedRTT plus ldquosafety marginrdquo

large variation in EstimatedRTT -gt larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

(typically = 025)

Then set timeout interval

Ch3-2 -10

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

Transport Layer 3-11

Host A

tim

eout

Host B

time

X

resend seq X2

seq x1seq x2seq x3seq x4seq x5

ACK x1

ACK x1ACK x1ACK x1

tripleduplicate

ACKs

Ch3-2 -12

event ACK received with ACK field value of y if (y gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer else increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) resend segment with sequence number y

Fast retransmit algorithm

a duplicate ACK for already ACKed segment

fast retransmit

Ch3-2 -13

TCP Flow Control

receive side of TCP connection has a receive buffer

speed-matching service matching the send rate to the receiving apprsquos drain rate app process may be

slow at reading from buffer

sender wonrsquot overflow

receiverrsquos buffer bytransmitting too

much too fast

flow control

Ch3-2 -14

TCP Flow control how it works

(Suppose TCP receiver discards out-of-order segments)

spare room in buffer= RcvWindow ( = rwnd)

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesnrsquot overflow The number of unACKed

data will be the smaller of RcvWindow and Congestion Window (to be discussed later)

Ch3-2 -15

TCP Connection Management

Recall TCP sender receiver establish ldquoconnectionrdquo before exchanging data segments

initialize TCP variables seq s buffers flow control info

(eg RcvWindow) client connection initiator Socket clientSocket = new

Socket(hostnameport

number) server contacted by client Socket connectionSocket =

welcomeSocketaccept()

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

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -9

TCP Round Trip Time and TimeoutSetting the timeout EstimtedRTT plus ldquosafety marginrdquo

large variation in EstimatedRTT -gt larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

(typically = 025)

Then set timeout interval

Ch3-2 -10

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

Transport Layer 3-11

Host A

tim

eout

Host B

time

X

resend seq X2

seq x1seq x2seq x3seq x4seq x5

ACK x1

ACK x1ACK x1ACK x1

tripleduplicate

ACKs

Ch3-2 -12

event ACK received with ACK field value of y if (y gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer else increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) resend segment with sequence number y

Fast retransmit algorithm

a duplicate ACK for already ACKed segment

fast retransmit

Ch3-2 -13

TCP Flow Control

receive side of TCP connection has a receive buffer

speed-matching service matching the send rate to the receiving apprsquos drain rate app process may be

slow at reading from buffer

sender wonrsquot overflow

receiverrsquos buffer bytransmitting too

much too fast

flow control

Ch3-2 -14

TCP Flow control how it works

(Suppose TCP receiver discards out-of-order segments)

spare room in buffer= RcvWindow ( = rwnd)

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesnrsquot overflow The number of unACKed

data will be the smaller of RcvWindow and Congestion Window (to be discussed later)

Ch3-2 -15

TCP Connection Management

Recall TCP sender receiver establish ldquoconnectionrdquo before exchanging data segments

initialize TCP variables seq s buffers flow control info

(eg RcvWindow) client connection initiator Socket clientSocket = new

Socket(hostnameport

number) server contacted by client Socket connectionSocket =

welcomeSocketaccept()

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

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -10

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

Transport Layer 3-11

Host A

tim

eout

Host B

time

X

resend seq X2

seq x1seq x2seq x3seq x4seq x5

ACK x1

ACK x1ACK x1ACK x1

tripleduplicate

ACKs

Ch3-2 -12

event ACK received with ACK field value of y if (y gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer else increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) resend segment with sequence number y

Fast retransmit algorithm

a duplicate ACK for already ACKed segment

fast retransmit

Ch3-2 -13

TCP Flow Control

receive side of TCP connection has a receive buffer

speed-matching service matching the send rate to the receiving apprsquos drain rate app process may be

slow at reading from buffer

sender wonrsquot overflow

receiverrsquos buffer bytransmitting too

much too fast

flow control

Ch3-2 -14

TCP Flow control how it works

(Suppose TCP receiver discards out-of-order segments)

spare room in buffer= RcvWindow ( = rwnd)

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesnrsquot overflow The number of unACKed

data will be the smaller of RcvWindow and Congestion Window (to be discussed later)

Ch3-2 -15

TCP Connection Management

Recall TCP sender receiver establish ldquoconnectionrdquo before exchanging data segments

initialize TCP variables seq s buffers flow control info

(eg RcvWindow) client connection initiator Socket clientSocket = new

Socket(hostnameport

number) server contacted by client Socket connectionSocket =

welcomeSocketaccept()

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

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Transport Layer 3-11

Host A

tim

eout

Host B

time

X

resend seq X2

seq x1seq x2seq x3seq x4seq x5

ACK x1

ACK x1ACK x1ACK x1

tripleduplicate

ACKs

Ch3-2 -12

event ACK received with ACK field value of y if (y gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer else increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) resend segment with sequence number y

Fast retransmit algorithm

a duplicate ACK for already ACKed segment

fast retransmit

Ch3-2 -13

TCP Flow Control

receive side of TCP connection has a receive buffer

speed-matching service matching the send rate to the receiving apprsquos drain rate app process may be

slow at reading from buffer

sender wonrsquot overflow

receiverrsquos buffer bytransmitting too

much too fast

flow control

Ch3-2 -14

TCP Flow control how it works

(Suppose TCP receiver discards out-of-order segments)

spare room in buffer= RcvWindow ( = rwnd)

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesnrsquot overflow The number of unACKed

data will be the smaller of RcvWindow and Congestion Window (to be discussed later)

Ch3-2 -15

TCP Connection Management

Recall TCP sender receiver establish ldquoconnectionrdquo before exchanging data segments

initialize TCP variables seq s buffers flow control info

(eg RcvWindow) client connection initiator Socket clientSocket = new

Socket(hostnameport

number) server contacted by client Socket connectionSocket =

welcomeSocketaccept()

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

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -12

event ACK received with ACK field value of y if (y gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer else increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) resend segment with sequence number y

Fast retransmit algorithm

a duplicate ACK for already ACKed segment

fast retransmit

Ch3-2 -13

TCP Flow Control

receive side of TCP connection has a receive buffer

speed-matching service matching the send rate to the receiving apprsquos drain rate app process may be

slow at reading from buffer

sender wonrsquot overflow

receiverrsquos buffer bytransmitting too

much too fast

flow control

Ch3-2 -14

TCP Flow control how it works

(Suppose TCP receiver discards out-of-order segments)

spare room in buffer= RcvWindow ( = rwnd)

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesnrsquot overflow The number of unACKed

data will be the smaller of RcvWindow and Congestion Window (to be discussed later)

Ch3-2 -15

TCP Connection Management

Recall TCP sender receiver establish ldquoconnectionrdquo before exchanging data segments

initialize TCP variables seq s buffers flow control info

(eg RcvWindow) client connection initiator Socket clientSocket = new

Socket(hostnameport

number) server contacted by client Socket connectionSocket =

welcomeSocketaccept()

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

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -13

TCP Flow Control

receive side of TCP connection has a receive buffer

speed-matching service matching the send rate to the receiving apprsquos drain rate app process may be

slow at reading from buffer

sender wonrsquot overflow

receiverrsquos buffer bytransmitting too

much too fast

flow control

Ch3-2 -14

TCP Flow control how it works

(Suppose TCP receiver discards out-of-order segments)

spare room in buffer= RcvWindow ( = rwnd)

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesnrsquot overflow The number of unACKed

data will be the smaller of RcvWindow and Congestion Window (to be discussed later)

Ch3-2 -15

TCP Connection Management

Recall TCP sender receiver establish ldquoconnectionrdquo before exchanging data segments

initialize TCP variables seq s buffers flow control info

(eg RcvWindow) client connection initiator Socket clientSocket = new

Socket(hostnameport

number) server contacted by client Socket connectionSocket =

welcomeSocketaccept()

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

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -14

TCP Flow control how it works

(Suppose TCP receiver discards out-of-order segments)

spare room in buffer= RcvWindow ( = rwnd)

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesnrsquot overflow The number of unACKed

data will be the smaller of RcvWindow and Congestion Window (to be discussed later)

Ch3-2 -15

TCP Connection Management

Recall TCP sender receiver establish ldquoconnectionrdquo before exchanging data segments

initialize TCP variables seq s buffers flow control info

(eg RcvWindow) client connection initiator Socket clientSocket = new

Socket(hostnameport

number) server contacted by client Socket connectionSocket =

welcomeSocketaccept()

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

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -15

TCP Connection Management

Recall TCP sender receiver establish ldquoconnectionrdquo before exchanging data segments

initialize TCP variables seq s buffers flow control info

(eg RcvWindow) client connection initiator Socket clientSocket = new

Socket(hostnameport

number) server contacted by client Socket connectionSocket =

welcomeSocketaccept()

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

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Transport Layer 3-16

TCP Connection Establishment (3-way)

Establishing a connection

Step 1 client sends TCP SYN control segment to server

Step 2 server receives SYN replies with SYN and ACK (in one segment)

Step 3 clients receives SYN+ACK replies with ACK and possible data

client

SYN + Initial Seq

server

ACK

ACK + possibly data

SYN + my initial Seq

1

2

est

ablis

hed

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -17

TCP Connection Close

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

client closes socket clientSocketclose()

Step 1 client sends FIN

Step 2 server receives FIN replies with ACK Sends FIN Waiting to close

Step 3 client receives FIN replies with ACK

Enters ldquotimed waitrdquo - will respond with ACK to received FINs

Step 4 server receives ACK Connection closed

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -18

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -19

Difficulty with Symmetric Release

Two-army problem when Blue army 1 can be sure that Blue army 2 will attack at the same time (never)

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -20

Disconnection Request (DR) = Attack

bull3-way handshake usually works

bullhosts 1 needs to retransmit DR several times

bullno perfect solution eg with a half-open connection in case (d) if the initial DR and all subsequent DRs are lost

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -21

Principles of Congestion Control

Congestion informally ldquotoo many sources sending too

much data too fast for network to handlerdquo different from flow control manifestations

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

a top-10 problem

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -22

Causescosts of congestion scenario 1

two senders two receivers

one router infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

bullLink capacity Cbullunlimited shared output link buffers

Host Ain original data

Host B

out

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -23

Causescosts of congestion scenario 2

one router finite buffers sender retransmission of ldquolostrdquo

packet upon timeout

finite shared output link buffers

Host A

in original data

Host B

outin original data plus retransmitted data

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -24

Causescosts of congestion scenario 2 Early timeout every packet retransmitted once (fig

a)

ldquoPerfectrdquo retransmission 1 retarns for 2 pkts (fig b)

ldquo costsrdquo of congestion more work (retrans) for given ldquogoodputrdquo unneeded retransmissions link carries multiple copies of pkt

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -25

Causescosts of congestion scenario 3 four senders multihop paths timeoutretransmit

in

Q what happens as and increase

in

finite shared output link buffers

Host A

in original data

Host B

outin original data plus

retransmitted data

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -26

Causescosts of congestion scenario 3

Another ldquocostrdquo of congestion when packet dropped any ldquoupstream transmission capacity

used for that packet was wasted

Host A

Host B

out

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -27

Approaches towards congestion control

End-end congestion control no explicit feedback from network congestion inferred from end-system (sender) observed

loss delay (eg TCP timeout)

Network-assisted congestion control routers provide feedback to end systems

single bit indicating congestion in ATM and TCPIP (new )

explicit rate sender should send at

Closed-Loop admission control prevents congestion Open-Loop monitors and deals with congestion

Two broad open-loop approaches

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -28

Network Assisted Congestion Control

bullNetwork feedback via receiver (in ATM and TCPIPrsquos ECN bit)

bullDirect network (router) feedback also called choke packets

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -29

TCP Congestion Control(Tahoe and Reno)

end-end control (no network assistance)

sender limits transmission LastByteSent-LastByteAcked min CongWin RcvWindow Roughly

CongWin is dynamic function of perceived network congestion

How does sender perceive congestion

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (CongWin) after loss event

Main mechanisms AIMD (cong avoidance

and fast recovery) slow start Fast retransmit

rate = CongWin

RTT Bytessec

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -30

TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease cut CongWin in half after a 3 Dup ACK in TCP Reno

(not in TCP Tahoe which uses Slow Start)

additive increase increase CongWin by 1 MSS every RTT in the absence of loss congestion avoidance

Long-lived TCP connection

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -31

TCP Slow Start

When connection begins CongWin = 1 MSS Example MSS = 500

bytes amp RTT = 200 msec

initial rate = 20 kbps

available bandwidth may be gtgt MSSRTT desirable to quickly

ramp up to respectable rate

When connection begins increase (ramp-up) rate exponentially fast until first loss event indicated by a triple dup (TD) ACK or time out (TO)

Slow at start but grows fast

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -32

TCP Slow Start (more)

When connection begins increase rate exponentially until first loss event double CongWin every

RTT done by incrementing

CongWin by 1 for every MSS Acked

TCP Tahoe (earliest version) slow start after either a TO or TD loss Ie Fast retransmit too

but no Fast recovery

Host A

one segment

RTT

Host B

time

two segments

four segments

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -33

Fast Retransmit (Reno)

After a TD loss CongWin cut in 12 window then grows

linearly (congestion avoidance)

But after a TO loss CongWin set to 1

MSS (slow start) window then grows

exponentially to a new threshold

then grows linearly (as in TD)

bull 3 dup ACKs indicates network capable of delivering some segmentsbull timeout before 3 dup ACKs is ldquomore alarmingrdquo

Philosophy

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

cong

estio

n w

indo

w s

ize

(s

egm

ents

)

TCP Tahoe

TCP Reno

TD LOSS

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -34

TCP Sender Congestion Control(see Table 33 for 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 CongWin2 and CongWin set to Threshold

When timeout occurs Threshold set to CongWin2 and CongWin is set to 1 MSS

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -35

TCP mechanisms Illustarted

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Transport Layer 3-36

TCP congestion control FSM details

slow start

congestionavoidance

fastrecovery

timeoutssthresh = cwnd2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment timeout

ssthresh = cwnd2 cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd gt ssthresh

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s)as allowed

new ACKcwnd = cwnd + MSS (MSScwnd)

dupACKcount = 0transmit new segment(s)as allowed

new ACK

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeoutssthresh = cwnd2cwnd = 1 dupACKcount = 0retransmit missing segment

cwnd = cwnd + MSStransmit new segment(s) as allowed

duplicate ACK

cwnd = ssthreshdupACKcount = 0

New ACK

cwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -37

Other TCP Variants

Inefficiency in high speed networks it takes long time for sender to recovery to original

cwnd after it being halved due to a packet loss HSTCP TCP-Westwood FAST Quick-Start Explicit

Transport Error Notification eXplicit Control Protocol (XCP)hellip

Inefficiency in wireless networks current TCP implementations are unable to

distinguish buffer overflow loss (congestion in wired networks) and random loss (in wireless networks)

Inefficiency in satellite network long propagation delay and large RTT indicate low

throughput TCP variants for wirelesssatellite networks

TCP-Peach Indirect-TCP (Split TCP) SNOOP Explicit Loss Notification (ELN)

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -38

TCP throughput

Whatrsquos the average throughout ot TCP as a function of window size and RTT Ignore slow start

Let W be the window size when loss occurs

When window is W throughput is WRTT Just after loss window drops to W2

throughput to W2RTT Average throughout (roughly) 75

WRTT

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -39

TCP Futures

Example 1500 byte segments 100ms RTT want 10 Gbps throughput

Requires window size W = 83333 in-flight segments even if no loss

Throughput in terms of loss rate

L = 210-10 Wow New versions of TCP for high-speed needed

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -40

High-Speed TCP (HSTCP)

Like standard TCP when cwnd is small More aggressive than standard TCP when cwnd is

large Increase window cwnd = cwnd + a(cwnd)

cwnd for every segment ACKed Decrease window cwnd = (1 ndash b(cwnd) ) cwnd

for every loss For standard TCP a(cwnd)=1 and b(cwnd)=05 HSTCP eg cwnd=83000 b(83000)=01means

decreasing 10 after a congestion event a(83000)=72 means an increase of 72 segments upon receiving one ACK

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -41

HSTCP

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -42

Fairness goal if K TCP sessions share same bottleneck link of bandwidth R each should have average rate of RK regardless the initial window size

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -43

Why is TCP fair

Two competing sessions Additive increase in throughput from (xy) with slope of 1 multiplicative decrease in throughput to (x+i2 y+i2)

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

xy

x+i y+i

(x+i)2 (y+i)2

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -44

Fairness (more)

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP pump audiovideo at

constant rate tolerate packet loss

Research area make themTCP friendly

Fairness and parallel TCP connections

Can open more than one parallel connections between 2 hosts (NetAnts)

Web browsers do this Example link of rate R

supporting 9 connections new app asks for 1 TCP

gets rate R10 new app asks for 9 TCPs

gets R2

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -45

Delay modeling

Q How long does it take to receive an object from a Web server after sending a request

Ignoring congestion delay is influenced by

TCP connection establishment

data transmission delay slow start

Notation assumptions Assume one link between

client and server of rate R S MSS (bits) O objectfile size (bits) no retransmissions (no loss

no corruption)

Window size First assume fixed

congestion window W segments

Then dynamic window modeling slow start

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -46

Fixed congestion window (1)

First caseWSR gt RTT + SR ACK for

first segment in window returns before windowrsquos worth of data sent

delay = 2RTT + OR

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -47

Fixed congestion window (2)

Second case WSR lt RTT + SR wait for ACK

after sending windowrsquos worth of data sent

ldquogaprdquo between two ldquoroundsrdquo is SR+RTT ndash WSR

Let K = O WS be the number of rounds

There are K-1 gaps

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -48

TCP Delay Modeling Slow Start (1)Now suppose window grows according to slow start And P is the number of rounds TCP idles at server (ie of gaps)Will show that the delay for one object is

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

pP

p

P

pp

)12(][2

]2[2

2delay

1

1

1

1)Let K be the number of sending roundswindows for the object (calculate K)

2)If the object data is large then when the max sending window is large enough eventually the idleTime will be 0 (after slow-start ends as assumed earlier)

3)Let Q be the last round during which idleTime is still gt 0then

This is the window size during

the p-th round in Slow-Start

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -49

TCP Delay Modeling Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Examplebull OS = 15 segmentsbull K = 4 windowsbull Q = 2bull P = minK-1Q = 2

Server idles P=2 times with a decreasing amt of idleTime

Delay componentsbull 2 RTT for connection estab and requestbull OR to transmit objectbull time server idles due to slow start

Server idles P = minK-1Q times

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -50

TCP Delay Modeling (3)

th window after the timeidle 2 1 pR

SRTT

R

S p

pth window the transmit totime2 1

R

Sp

RTT

initia te TCPconnection

requestobject

first w indow= S R

second w indow= 2S R

third w indow= 4S R

fourth w indow= 8S R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -51

TCP Delay Modeling (4)

Calculation of Q number of idles for infinite-size objectis similar largest Q st

SR+ RTT gt=

Recall K = number of windows that cover object

How do we calculate K

R

SQ 12

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -52

Effect of Slow Start Delay is affected by

Fileobject size O Transmission rate R Fixed window size or MSS idle time RTT Extra delay due to slow start

With a large O and small R and RTT Slow start does not hurt much

With a small O and large RxRTT Slow start hurts significantly (percentage

wise)

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -53

Food For Thought Assume Web page consists of

1 base HTML page (of size O bits) M images (each of size O bits)

Non-persistent HTTP M+1 TCP connections in series Response time = (M+1)OR + (M+1)2RTT + sum of

idle times What about Persistent HTTP What about Non-persistent HTTP with X parallel

connections (is this X times fast than having 1 non-persistent HTTP)

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -54

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)RTT = 100 msec O = 5 Kbytes M=10 and X=5

For low bandwidth connection amp response time dominated by transmission time

Persistent connections only give minor improvement over parallel connections

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -55

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP Response time (in seconds)

RTT =1 sec O = 5 Kbytes M=10 and X=5

For larger RTT response time dominated by TCP establishment amp slow start delays Persistent connections now give important improvement particularly in high delaybandwidth networks

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary

Ch3-2 -56

Chapter 3 Summary principles behind

transport layer services reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next leaving the network

ldquoedgerdquo (application transport layers)

into the network ldquocorerdquo

• Chapter 3 outline
• TCP Overview RFCs 793 1122 1323 2018 2581
• TCP segment structure
• TCP seq rsquos and ACKs
• TCP retransmission scenarios
• TCP Round Trip Time and Timeout
• Slide 7
• Example RTT estimation
• Slide 9
• Fast Retransmit
• PowerPoint Presentation
• Fast retransmit algorithm
• TCP Flow Control
• TCP Flow control how it works
• TCP Connection Management
• TCP Connection Establishment (3-way)
• TCP Connection Close
• TCP Connection Management (cont)
• Difficulty with Symmetric Release
• Disconnection Request (DR) = Attack
• Principles of Congestion Control
• Causescosts of congestion scenario 1
• Causescosts of congestion scenario 2
• Slide 24
• Causescosts of congestion scenario 3
• Slide 26
• Approaches towards congestion control
• Network Assisted Congestion Control
• TCP Congestion Control (Tahoe and Reno)
• TCP AIMD
• TCP Slow Start
• TCP Slow Start (more)
• Fast Retransmit (Reno)
• TCP Sender Congestion Control (see Table 33 for TCP Reno)
• TCP mechanisms Illustarted
• TCP congestion control FSM details
• Other TCP Variants
• TCP throughput
• TCP Futures
• High-Speed TCP (HSTCP)
• HSTCP
• TCP Fairness
• Why is TCP fair
• Fairness (more)
• Delay modeling
• Fixed congestion window (1)
• Fixed congestion window (2)
• TCP Delay Modeling Slow Start (1)
• TCP Delay Modeling Slow Start (2)
• TCP Delay Modeling (3)
• TCP Delay Modeling (4)
• Effect of Slow Start
• Food For Thought
• Slide 54
• Slide 55
• Chapter 3 Summary