Transmission Control Protocol

Notes derived from “Computer Networking: A Top Down

Approach Featuring the Internet”, 2005, 3rd edition, Jim
Kurose, Keith Ross, Addison-Wesley.

1
TCP: Features/Context
 Connection-oriented
 State vars, buffer etc
 Routers are oblivious to TCP
 Full-duplex service
 Point-to-Point Service
 Three-way handshake for con. Est.

2
TCP: Context
 MSS(Maximum Segment Size)
 Max amount of app data
 It is the maximum size of the body of
transport segment
 MTU (Maximum Transmission Unit)
 Largest link layer frame
 Send Buffer/Receive Buffer
 It breaks the file into MSS
 TCP header is typically 20 byte

3
 TCP segment structure
32 bits
URG: urgent data counting
(generally not used) source port # dest port #
by bytes
sequence number of data
ACK: ACK #
valid acknowledgement number (not segments!)
head not
PSH: push data now len used
UA P R S F Receive window
(generally not used) # bytes
checksum Urg data pnter
rcvr willing
RST, SYN, FIN: to accept
Options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)

4
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 – numbering of data is
independent in each direction
 Acknowledgement number – sequence
number of the next byte expected from
the sender
 ACKs are cumulative

5
 TCP seq. #’s and ACKs
Seq. #’s:
Host A Host B
 byte stream “number”
of first byte in 1000 byte Seq=4
data 2,
segment’s data ACK=
79, da
t a
ACKs: host ACKs
 seq # of next byte receipt of
data data
expected from other 10 4 2 no
CK=
side Seq=
79, A
 cumulative ACK

Q: how receiver handles Host sends

out-of-order segments another Seq=1
500 bytes 042, A
CK=79
 A: TCP spec doesn’t , data
say, - up to
implementor 4 2, no
d ata
= 15
=79 , ACK time
Seq

6
 TCP seq. #’s and ACKs(n)
Seq. #’s:
Host A Host B
 byte stream “number”
of first byte in 1000 byte Seq=4
data 2,
segment’s data ACK=
79, da
t a
ACKs: host ACKs
 seq # of next byte receipt of
d ata data
expected from other =10 4 3, no
side =7 9 , ACK
Seq
 cumulative ACK

Q: how receiver handles Host sends

out-of-order segments another Seq=1
500 bytes 04 3, ACK
 A: TCP spec doesn’t =79, d
at a
say, - up to
implementor 4 4, no
d ata
= 15
=79 , ACK time
Seq

CPSC 441:TCP 7
TCP: Cumulative ACK/Dupack
1001
ACK 2001
2000

2001
3000

3001 ACK 2001

4000

4001
ACK 2001
5000

5001 ACK 2001

6000
TCP: Cumulative ACK/Dupack
1001
2000

2001
3000

3001 This segment is lost

4000

4001
5000 Generate all the acknowledgement. Assume that no
acks are lost.

5001
6000
TCP: Cumulative ACK/Dupack
1001
2000

2001
3000

3001 This segment is lost

4000

4001
This segment is lost
5000

5001 Generate all the acknowledgement. Assume that no

acks are lost.
6000
TCP: Cumulative ACK/Dupack
1001 1001

2000 2000

2001 2001

3000 3000

A 3001 3001 B
4000 4000

4001 4001

5000 5000

Generate all the acknowledgements

5001 received by A. Assume that no acks are 5001
lost.
6000 6000
TCP
 Let we have a TCP connection between G and H. A
transmission segment is denoted by
Seg(SB:1,EB:500). It implies the segment carries
byte starting from 1 to 500 (SB=Starting byte,
EB=Ending byte). Let G transmits Seg(SB:1,EB:500),
Seg(SB:501,EB:1000), Seg(SB:1001,EB:1212),
Seg(SB:1213,EB:2000), Seg(SB:2001,EB:2500),
Seg(SB:2501,EB:3000) and Seg(SB:3001,EB:3533).
Among them, Seg(SB:1213,EB:2000) and
Seg(SB:2001,EB:2500) are lost. Now, determine
ACK sequence received by G. Assume that no ACKs
are lost.
TCP: Phases
 TCP State Variables
 Cwnd: congestion window
• Specifies the number of segments sent per rtt
 Ssthresh: slow-start threshold
• A threshold parameter that determines the phases of
TCP
 Congestion Avoidance
 TCP is in congestion avoidance when cwnd >=
ssthresh
 During congestion avoidance, TCP increases the
cwnd by 1 in every RTT

13
TCP: Phases
 Slow Start
 TCP is in slow-start when cwnd < ssthresh
 During congestion avoidance, TCP increases the
cwnd by 1 with every receipt ACK

14
TCP: Reliable Transfer
 Unreliable transfer can occur due to
 Router overflow
 Out of order delivery
 Corruption

 To make reliable, we do retransmission based

on
 Timeout
 Duplicate ack

15
TCP: Reliable Transfer
data rcvd from app: timeout:
 When timer expires,
 Create segment with
timeout event is triggered
seq #  retransmit segment that
 seq # is byte-stream caused timeout
number of first data  restart timer
byte in segment Dupack:
 start timer if not  If we receive 3 or more

already running (think dupacks, this event is

triggered
of timer as for oldest  It implies loss
unacked segment)  Action: Retransmit the
 expiration interval: segment
TimeOutInterval

16
TCP Flow Control
flow control
sender won’t overflow
 receive side of TCP
receiver’s buffer by
connection has a transmitting too
receive buffer: much,
too fast

 speed-matching
service: matching the
send rate to the
receiving app’s drain
rate
 app process may be
slow at reading from
buffer
17
TCP Flow control: how it works
 Rcvr advertises spare
room by including value
of RcvWindow in
segments
 Sender limits unACKed
(Suppose TCP receiver data to RcvWindow
discards out-of-order  guarantees receive
segments) buffer doesn’t overflow
 spare room in buffer
= RcvWindow
= RcvBuffer-[LastByteRcvd -
LastByteRead]

18
 TCP Connection Establishment (n)

CLOSED client server

Passive open Active open;

SYN,
SYN seq=x
SYN/SYN+ACK LISTEN
ac k =x+1
SYN_SENT q =y ,
SYN_RCVD A CK,
se
+
SYN
SYN+ACK/ACK ACK,
ack =y+1
ACK
Established

Solid line for client

Dashed line for server

19
TCP Connection Termination (n)

client server
closing
FIN_WAIT1 F IN

CLOSE_WAIT
ACK
LAST_ACK
FIN_WAIT2 FIN

TIME_WAIT
timed wait

ACK

CLOSED

CLOSED

20
Principles of Congestion Control (n)
 Congestion: informally: “too many sources
sending too much data too fast for network to
handle”
 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

21
Congestion Control: Approaches
(n)
 Goal: Throttle senders as needed to ensure
load on the network is “reasonable”
 End-end congestion control:
 no explicit feedback from network
 congestion inferred from end-system
observed loss, delay
 approach taken by TCP

 Network-assisted congestion control:

 routers provide feedback to end systems
 single bit indicating congestion (e.g., ECN)
 explicit rate sender should send at

22
TCP Congestion Control: Overview
 Congestion detection
 Timeout
 Dupacks

 Congestion action
 Action for timeout
• Reduce transmission rate to 1 seg/rtt
 Action for dupack
• Reduce transmission rate to half

23