CPSC 441:TCP1 Instructor: Anirban Mahanti Office: ICT 745 Email: mahanti@cpsc.ucalgary.ca Class Location: ICT 121 Lectures: MWF 12:00 – 12:50 Notes derived.

CPSC 441TCP 1

Instructor Anirban MahantiOffice ICT 745Email mahanticpscucalgarycaClass Location ICT 121Lectures MWF 1200 ndash 1250Notes derived from ldquoComputer Networking A Top

Down Approach Featuring the Internetrdquo 2005 3rd edition Jim Kurose Keith Ross Addison-Wesley

Slides are adapted from the companion web site of the

book as modified by Anirban Mahanti (and Carey Williamson)

Transmission Control Protocol

CPSC 441TCP 2

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

countingby bytes of data(not segments)

Internetchecksum

(as in UDP)

CPSC 441TCP 3

Sequence and Acknowledgement Number TCP views data as unstructured but

ordered stream of bytes Sequence numbers are over bytes not

segments Initial sequence number is chosen

randomly TCP is full duplex ndash numbering of data is

independent in each direction Acknowledgement number ndash sequence

number of the next byte expected from the sender

ACKs are cumulative

CPSC 441TCP 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

Seq=79 ACK=1043 no data

Seq=1043 ACK=79 data

1000 bytedata

Host sends another

500 bytes

host ACKsreceipt of

data

timeSeq=79 ACK=1544 no data

CPSC 441TCP 5

TCP reliable data transfer

TCP creates rdt service on top of IPrsquos unreliable service

Pipelined segments Cumulative acks TCP uses single

retransmission timer

Retransmissions are triggered by timeout events duplicate acks

Initially consider simplified TCP sender ignore duplicate acks ignore flow control

congestion control

CPSC 441TCP 6

TCP sender eventsdata rcvd from app Create segment with

seq seq is byte-stream

number of first data byte in segment

start timer if not already running (think of timer as for oldest unacked segment)

expiration interval TimeOutInterval

timeout retransmit segment

that caused timeout restart timer Ack rcvd If acknowledges

previously unacked segments update what is known

to be acked start timer if there are

outstanding segments

CPSC 441TCP 7

TCP sender(simplified)

NextSeqNum = InitialSeqNum SendBase = InitialSeqNum

loop (forever) switch(event)

event data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data)

event timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer

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

end of loop forever

Commentbull SendBase-1 last cumulatively ackrsquoed byteExamplebull SendBase-1 = 71y= 73 so the rcvrwants 73+ y gt SendBase sothat new data is acked

CPSC 441TCP 8

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

CPSC 441TCP 9

TCP Flow control how it works

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

spare room in buffer= RcvWindow

= 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

CPSC 441TCP 10

Silly Window Syndrome

Recall TCP uses sliding window ldquoSilly Windowrdquo occurs when small-sized

segments are transmitted resulting in inefficient use of the network pipe

For eg suppose that TCP sender generates data slowly 1-byte at a time

Solution wait until sender has enough data to transmit ndash ldquoNaglersquos Algorithmrdquo

CPSC 441TCP 11

Naglersquos Algorithm

1 TCP sender sends the first piece of data obtained from the application (even if data is only a few bytes)

2 Wait until enough bytes have accumulated in the TCP send buffer or until an ACK is received

3 Repeat step 2 for the remainder of the transmission

CPSC 441TCP 12

Silly Window Continued hellip

Suppose that the receiver consumes data slowly Receive Window opens slowly and thus

sender is forced to send small-sized segments

Solutions Delayed ACK Advertise Receive Window = 0 until

reasonable amount of space available in receiverrsquos buffer

CPSC 441TCP 13

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

CPSC 441TCP 14

TCP Connection Establishment

client

SYN seq=x

server

SYN+ACK seq=y ack=x+1

ACK ack=y+1

CLOSED

LISTEN

SYN_SENTSYN_RCVD

Established

Passive open

SYNSYN+ACK

ACK

Active openSYN

SYN+ACKACK

Solid line for client

Dashed line for server

CPSC 441TCP 15

TCP Connection Termination

client

FIN

server

ACK

ACK

FIN

closing

tim

ed w

ait

FIN_WAIT1

FIN_WAIT2

CLOSE_WAIT

LAST_ACK

CLOSED

TIME_WAIT

CLOSED

CPSC 441TCP 16

Principles of Congestion Control Congestion informally ldquotoo many sources

sending too much data too fast for network to handlerdquo

Different from flow control Manifestations

Packet loss (buffer overflow at routers) Increased end-to-end delays (queuing in router

buffers) Results in unfairness and poor utilization of

network resources Resources used by dropped packets (before they

were lost) Retransmissions Poor resource allocation at high load

CPSC 441TCP 17

Historical Perspective

October 1986 Internet had its first congestion collapse

Link LBL to UC Berkeley 400 yards 3 hops 32 Kbps throughput dropped to 40 bps factor of ~1000 drop

Van Jacobson proposes TCP Congestion Control Achieve high utilization Avoid congestion Share bandwidth

CPSC 441TCP 18

Congestion Control Approaches Goal Throttle senders as needed to ensure

load on the network is ldquoreasonablerdquoEnd-end congestion control

no explicit feedback from network congestion inferred from end-system

observed loss delay approach taken by TCP

Network-assisted congestion control routers provide feedback to end systems single bit indicating congestion (eg ECN) explicit rate sender should send at

CPSC 441TCP 19

TCP Congestion Control Overview end-end control (no network assistance) Limit the number of packets in the

network to window W Roughly

W is dynamic function of perceived network congestion

rate = W

RTT Bytessec

CPSC 441TCP 20

TCP Congestion Controls Tahoe (Jacobson 1988)

Slow Start Congestion Avoidance Fast Retransmit

Reno (Jacobson 1990) Fast Recovery

SACK Vegas (Brakmo amp Peterson 1994)

Delay and loss as indicators of congestion

CPSC 441TCP 21

data segment

Slow Start ldquoSlow Startrdquo is used to

reach the equilibrium state Initially W = 1 (slow start) On each successful ACK

W W + 1 Exponential growth of W

each RTT W 2 x W Enter CA when

W gt= ssthresh ssthresh window size

after which TCP cautiously probes for bandwidth

ACK

sendercwnd

1

2

34

5678

receiver

CPSC 441TCP 22

ACK

data segment

Congestion Avoidance

Starts when W ssthresh

On each successful ACKW W+ 1W

Linear growth of W each RTT

W W + 1

1

2

3

4

receiversender

CPSC 441TCP 23

CA Additive Increase Multiplicative Decrease

We have ldquoadditive increaserdquo in the absence of loss events

After loss event decrease congestion window by half ndash ldquomultiplicative decreaserdquo ssthresh = W2 Enter Slow Start

CPSC 441TCP 24

Detecting Packet Loss

Assumption loss indicates congestion

Option 1 time-out Waiting for a time-out

can be long

Option 2 duplicate ACKs How many At least

3

11

13

12

1415

17

16

11

10

X

11

11

10

11

Sender Receiver

CPSC 441TCP 25

Fast Retransmit

Wait for a timeout is quite longImmediately retransmits after 3

dupACKs without waiting for timeout

Adjusts ssthreshssthresh W2

Enter Slow Start W = 1