CSE 3711

-Computer Networks “Transport Layer”-

Prof. Dr. A.K.M. Muzahidul Islam
Computer Science & Engineering (CSE)
United International University (UIU)

Summer 2023
 Chapter 3
Transport Layer
(Sec – 3.1, 3.2, 3.3, 3.4,
3.5 & 3.7)
Notes derived from “Computer Networking: A Top
Down Approach”, Jim Kurose, Keith Ross,
Addison-Wesley.
Computer
Slides are adapted from the companion web site of Networking: A Top
the book, as modified Down Approach
by Prof. Dr. A.K.M. Muzahidul Islam. 7th edition
Jim Kurose, Keith Ross
Addison-Wesley
March 2017

Introduction 1-2
Transport layer: overview
Our goal:
 understand principles  learn about Internet transport
behind transport layer layer protocols:
services: • UDP: connectionless transport
• multiplexing, • TCP: connection-oriented reliable
demultiplexing transport
• reliable data transfer • TCP congestion control
• flow control
• congestion control

Transport Layer: 3-3

3.1 Transport services and protocols
applicatio
n

 Transport Layer Protocols provide logical mobile

transport
network
network

communication between application

data link
physical national or global ISP

processes running on different hosts

log
ica
 Transport Layer Protocols are implemented

l en
in the End Systems, NOT in Network Routers

d-e
nd
local or
 Transport protocols actions in end systems:

t
ran
regional
ISP
• Sender: breaks application messages into

spor
segments, passes to network layer home network content

t
provider
• Receiver: reassembles segments into messages, network
applicatio
datacenter
network
passes to application layer n
transport
 Two transport protocols available to Internet network
data link
applications physical

• TCP, UDP enterprise

network
• Each of them provides a different set of Transport-
Layer Services to the Application
Transport Layer: 3-4
Transport vs. network layer services and protocols

 Transport Layer Protocol: household analogy:

Provides Logical 12 kids in Ann’s house sending
Communication between letters to 12 kids in Bill’s house:
processes running on  hosts = houses
different hosts  processes = kids
• relies on, enhances, network  app messages = letters in
layer services envelopes
• Network Layer Protocol:  transport protocol = Ann and Bill
Provides Logical who demux to in-house siblings
communication between  network-layer protocol = postal
service
hosts
Transport Layer: 3-5
Transport Layer in the Internet
 Internet makes 02 distinct Transport-Layer protocols available to the
application layer:
• UDP – User Datagram Protocol
• Provides an Unreliable, Connectionless Services to the Invoking Application
• TCP – Transmission Control Protocol
• Provides a Reliable, Connection-oriented Services to the Invoking Application
 When designing a Network Application, the application developer selects
between UDP and TCP.
 Transport Layer Packet for TCP is referred as a Segment.
 Transport Layer Packet for UDP is referred as a Datagram.
 Network Layer Protocol has a name – IP: Internet Protocol, which provides
Logical Communication between hosts.
 Every host has at least one IP address.
 IP Service Model is a best-effort delivery service
• Makes its best effort to deliver segments between hosts
• However, makes No Guarantees, thus called as Unreliable Service
Transport Layer: 3-6
Two principal Internet transport protocols
applicatio
n

 TCP: Transmission Control mobile

transport
network
network
data link

Protocol physical national or global ISP

log
• reliable, in-order delivery

ica
l en
• congestion control

d-e
• flow control

nd
local or

t
ran
regional
• connection setup ISP

spor
home network
 UDP: User Datagram Protocol content

t
provider
network datacenter
• unreliable, unordered delivery applicatio
n
transport
network

• no-frills extension of “best-effort” IP network

data link
physical

• it is known as best-effort IP due to its enterprise

network
error handling capacity.
 services not available: Transport Layer: 3-7

• delay guarantees
• bandwidth guarantees
Transport Layer Actions

Sender:
application  is passed an application- app. msg
application
layer message
transport
 determines segment TTh htransport
app. msg
header fields values
network (IP)
 creates segment network (IP)

link
 passes segment to IP link

physical physical

Transport Layer: 3-8

Transport Layer Actions

Receiver:
application  receives segment from IP application
 checks header values
app. msg
transport  extracts application-layer transport
message
network (IP)  demultiplexes message up network (IP)

link to application via socket link

physical physical
Th app. msg

Transport Layer: 3-9

 3.2 Multiplexing/demultiplexing
demultiplexing at receiver:
multiplexing at sender: use header info to deliver
handle data from multiple received segments to correct
sockets, add transport header socket
(later used for demultiplexing)

application

application P1 P2 application socket

P3 transport P4
process
transport network transport
network link network
link physical link
physical physical

Transport Layer: 3-10

• Multiplexing : The job of gathering data chunks at the source host from
different sockets, encapsulating each data chunk with header information to
create segments and passing the segments to the network layer.

• Demultiplexing : The job of delivering the data in a transport-layer segment to

the correct socket.
How demultiplexing works
 host receives IP datagrams 32 bits
• each datagram has source IP source port # dest port #
address, destination IP address
• each datagram carries one other header fields
transport-layer segment
• each segment has source,
application
destination port number data
 host uses IP addresses & port (payload)
numbers to direct segment to
appropriate socket TCP/UDP segment format

Transport Layer: 3-11

3.3 UDP: User Datagram Protocol
 “no frills i.e. no extra or Why is there a UDP?
unnecessary details,” “bare bones”  no connection
Internet transport protocol establishment (which can
 “best effort” service, UDP add RTT delay)
segments may be:  simple: no connection state
• lost at sender, receiver
 small header size
• delivered out-of-order to app
 connectionless:  no congestion control
 UDP can blast away as fast
• no handshaking between UDP as desired!
sender, receiver  can function in the face of
• each UDP segment handled congestion
independently of others
Transport Layer: 3-12
 UDP: User Datagram Protocol
 Aside from Multiplexing/Demultiplexing functions and Some
Light Error Checking, it adds nothing to IP.
 i.e. the application is almost directly talking with IP
 UDP takes messages from the application process, attaches
Source and Destination Port Number Fields, adds two other
small fields and passes the segment to the Network Layer.
 UDP use:
 streaming multimedia apps (loss tolerant, rate sensitive)
 DNS
 SNMP – Simple Network Management Protocol
 HTTP/3 – More recent version of HTTP
 if reliable transfer needed over UDP (e.g., HTTP/3):
 add needed reliability at application layer Transport Layer: 3-13

 add congestion control at application layer

UDP: Transport Layer Actions

SNMP client SNMP server

application application

transport transport
(UDP) (UDP)

network (IP) network (IP)

link link

physical physical

Transport Layer: 3-14

UDP: Transport Layer Actions

SNMP client SNMP server

UDP sender actions:
application  is passed an application- SNMP msg
application
layer message
transport  determines UDP segment UDPtransport
UDP h h SNMP msg

(UDP) header fields values (UDP)

network (IP)
 creates UDP segment network (IP)

link
 passes segment to IP link

physical physical

Transport Layer: 3-15

UDP: Transport Layer Actions

SNMP client SNMP server

UDP receiver actions:
application  receives segment from IP application
 checks UDP checksum
transport transport
SNMP msg header value
(UDP)  extracts application-layer (UDP)

network
UDP h SNMP(IP)
msg message network (IP)
 demultiplexes message up
link to application via socket link

physical physical

Transport Layer: 3-16

 UDP segment header
32 bits
source port # dest port #
length checksum

application length, in bytes of

data UDP segment,
(payload) including header

data to/from
UDP segment format application layer

Application Data : Occupies the data field of the UDP segment.

Length Field : No. of bytes in UDP segment i.e. HeaderTransport
+ [Link]: 3-17

Checksum : Used by the receiving host to check whether

errors have been introduced into the segment.
Exercise: Spring 2023

 Suppose that a process running with port 61 is using a UDP

segment is to send the following 2 bits to another process
with port 53.
 01011010 01110001

 Now answer the following questions:

• What will be length (in bytes) of the UDP segment that will be sent from the
transport layer? [ 1.5 ]
• What fields are contained in the headers of a UDP segment? How big are each of
these fields? [ 1.5 ]
• Calculate the checksum for the UDP segment. The checksum of a UDP segment is 2
bytes long (having values between 0 and 65535), and it is calculated over the entire
UDP segment, including the UDP headers and the data payload. [ 1.5 ]
 What will be the values of each of the fields of the header of
the UDP segment that is being sent in the given scenario?
[ 1.5 ]
Transport Layer: 3-18
 Checksum

• Transmitting Side
1100 0010
0010 0010
+ 1100 ------
1000 0100
Flip -> 1011
---------------
(Checksum)
0010 0010
• Receiving Side 0010
0010 0010 1101
------
+ 1011 (Checksum)
1111
---------------------- Flip -> 0000
0010 1101 (Correct)
 CRC Example
 Send • Receive
• M(x) = 110011  x5+x4+x+1 (6 bits)
• P(x) = 11001  x4+x3+1 (5 bits, n = 4) 11001 1100111001
 4 bits of redundancy 11001
• Form xnM(x)  110011 0000
 x9+x8+x5+x4 11001
• Divide xnM(x) by P(x) to find C(x)
11001
100001 00000
11001 1100110000
11001
10000
No remainder
11001  Accept
1001= C(x)
Send the block 110011 1001
 3.4 Principles of reliable data transfer
sending receiving
process process
application dat dat
transport a a
reliable channel

reliable service abstraction

• The Figure illustrates the framework of reliable data transfer.

• The service abstraction provided to the upper-layer entities is that of
a reliable channel through which data can be transferred.
• With a reliable channel,
• no transferred data bits are corrupted or lost, and
• all data are delivered in the order in which they were sent.
• This is precisely the service model offered by TCP to the Internet
applications that invoke it.

Transport Layer: 3-22

 Principles of reliable data transfer
sending receiving sending receiving
process process process process
application dat dat application dat dat
transport a a transport a a
reliable channel
sender-side of receiver-side
reliable service abstraction reliable data of reliable data
transfer protocol transfer protocol

transport
network
unreliable channel
reliable service implementation

• It is the responsibility of a reliable data transfer protocol to implement this

service abstraction.
• The task is made difficult by the fact that the layer below the reliable data
transfer protocol may be unreliable.
• For example, TCP is a reliable data transfer protocol that is
implemented on top of an unreliable (IP) end-to-end network layer.
Transport Layer: 3-23
Principles of reliable data transfer

sending receiving
process process
application dat dat
transport a a

sender-side of receiver-side
However, reliable data
transfer protocol
of reliable data
transfer protocol
The Complexity of reliable data
transfer protocol will depend transport
network
(strongly) on characteristics of unreliable channel
unreliable channel (lose,
reliable service implementation
corrupt, reorder data?)
Transport Layer: 3-24
Principles of reliable data transfer

sending receiving
process process
application dat dat
transport a a

sender-side of receiver-side
reliable data of reliable data
Sender, receiver do not know transfer protocol transfer protocol
the “state” of each other, e.g.,
was a message received? transport
network
 unless communicated via a unreliable channel

message
reliable service implementation

Transport Layer: 3-25

 Reliable data transfer protocol (rdt)

 We incrementally develop the

sender and receiver sides of a
reliable data transfer protocol,
considering increasingly complex
models of the underlying
channel.
 For example, what protocol
mechanisms are needed when
the underlying channel can
corrupt bits or lose entire
packets.
 One assumption is that packets
will be delivered in the order in
which they were sent, with some
packets possibly being lost; that
is, the underlying channel will
not reorder packets.
Transport Layer: 3-26
 Reliable data transfer protocol (rdt): interfaces

Sending Side Receiving Side

1. rdt_send(): called from 4. deliver_data(): called by

above, (e.g., by app.). rdt to deliver data to upper
Passed data to deliver to layer
receiver upper layer sending receiving
process process
rdt_send() dat dat
a a deliver_data()
Both the send
sender-side data receiver-side
and receive implementation of implementation of
sides of rdt send rdt reliable data packet rdt reliable data
packets to the transfer protocol transfer protocol
other side by a udt_send() Heade dat Heade dat rdt_rcv()
r a r a
call to udt_send() unreliable channel

2. udt_send(): called by rdt 3. rdt_rcv(): called when

to transfer packet over Bi-directional communication over packet arrives on receiver side
unreliable channel to receiver unreliable channel of channel
Transport Layer: 3-27

Figure indicates only Unidirectional i.e. data transfer from the sending to the receiving side.
• Bi-directional : data transfer from both sending and receiving sides.
 Reliable Data Transfer over a Perfectly
Reliable Channel: rdt1.0

 Case 1 - where the underlying channel is

completely reliable.
 The finite-state machine (FSM) definitions
for the rdt1.0 sender and receiver are
shown in Figure 3.9.
 The FSM in Figure 3.9(a) defines the
operation of the sender, while the FSM in
Figure 3.9(b) defines the operation of the
receiver
The sending side of rdt
 simply accepts data from the upper layer
via the rdt_send(data) event,
 creates a packet containing the data (via
the action make_pkt(data)) and
 sends the packet into the channel.
 In practice, the rdt_send(data) event would
result from a procedure call (for example,
to rdt_send()) by the upper-layer Transport Layer: 3-28
On the receiving side,
 rdt receives a packet from the
underlying channel via the
rdt_rcv(packet) event,
 Removes the data from the
packet (via the action extract
(packet, data)) and
 passes the data up to the upper
layer (via the action
deliver_data(data)).
 In practice, the rdt_rcv(packet)
event would result from a
procedure call (for example, to
rdt_rcv()) from the lowerlayer
protocol.
Transport Layer: 3-29
Reliable Data Transfer over a Channel with
Bit Errors: rdt2.0

 A more realistic model of the  In a computer network setting,

underlying channel is one in reliable data transfer protocols
which bits in a packet may be based on such retransmission are
corrupted. known as ARQ (Automatic Repeat
 Such bit errors typically occur in reQuest) protocols.
the physical components of a  03 additional protocol capabilities
network as a packet is are required in ARQ protocols to
transmitted, propagates, or is handle the presence of bit errors:
buffered. • Error Detection
• UDP uses Internet Checksum field
 The message-dictation protocol
• Receiver Feedback
uses both
• The positive (ACK) and
• positive acknowledgments (“OK”) • Negative (NAK) acknowledgment replies
• negative acknowledgments • Retransmission
(“Please repeat that.”)

Transport Layer: 3-30

 Figure 3.10
shows the FSM
representation
of rdt2.0, a
data transfer
protocol
employing
error
detection,
positive
acknowledgme
nts, and
negative
acknowledgme
nts.

Transport Layer: 3-31

 stop-and-wait operation (Non-pipelined)
sender receive
r
first packet bit transmitted, t = 0

first packet bit arrives

Round-trip time (RTT) last packet bit arrives, send
ACK

ACK arrives, send next

packet, t = RTT + L / R

• The sender will not send a new piece of data until it is sure that the
receiver has correctly received the current packet.
• Because of this behavior, protocols such as rdt2.0 are known as stop-
and-wait protocols.
• When the sender is in the wait-for-ACK-or-NAK state, it cannot get
more data from the upper layer; that is, the rdt_send() event occurs
after the sender receives an ACK.
• Sender send a new piece of data iff receiver has correctly received the
current packet. Thus, rdt2.0 is known as stop-and-wait protocols.
Reliability in action (Stop-and-Wait)
• The sender does not know whether a data packet was lost, an ACK was
lost, or if the packet or ACK was simply overly delayed.
• In all cases, the action is the same: retransmit.
• Time-based retransmission mechanism requires a countdown timer.
• The sender will need to (1) start the timer each time a packet is sent
• (2) respond to a timer interrupt
• (3) stop the timer.
sender receiver sender receiver
send pkt0 pkt0 send pkt0 pkt0
rcv pkt0 rcv pkt0
ack send ack0 ack0 send ack0
rcv ack0 0 rcv ack0
send pkt1 pkt1 send pkt1 pkt1
rcv pkt1 X
loss
ack1 send ack1
rcv ack1
send pkt0 pkt0
rcv pkt0 timeout
ack0 send ack0 resend pkt1 pkt1
rcv pkt1
ack1 send ack1
rcv ack1
send pkt0 pkt0
(a) no loss rcv pkt0
ack0 send ack0

(b) packet loss Transport Layer: 3-33

Figure 3.16 Operation of rdt3.0, the alternating-bit protocol

 Reliability in action (Stop-and-Wait)
• Because packet sequence numbers alternate between 0 and 1,
protocol rdt3.0 is sometimes known as the alternating-bit protocol.

sender receiver
sender receiver send pkt0
pkt0
rcv pkt0
send pkt0 pkt0 send ack0
ack
rcv pkt0 rcv ack0
send ack0 send pkt1 0
ack pkt
rcv ack0 0 1 rcv pkt1
send pkt1 pkt send ack1
1 rcv pkt1 ack1
ack1 send ack1
X timeout
loss resend pkt1
pkt1 rcv pkt1
timeout
resend pkt1 pkt1
rcv pkt1 rcv ack1 (detect duplicate)
send pkt0 pkt0 send ack1
(detect duplicate)
ack1 send ack1 ack1 rcv pkt0
rcv ack1 rcv ack1 send ack0
send pkt0 pkt0 (ignore) ack0
rcv pkt0
ack0 send ack0 pkt
1

(c) ACK loss (d) premature timeout/ delayed ACK

Transport Layer: 3-34

Figure 3.16 Operation of rdt3.0, the alternating-bit protocol

The performance impact of this stop-and-wait
behavior
 Consider an idealized case of two hosts, one located on the West Coast of the
United States and the other located on the East Coast. The speed-of-light
round-trip propagation delay between these two end systems, RTT, is
approximately 30 milliseconds.
 Suppose that they are connected by a channel with a transmission rate, R, of
1 Gbps (109 bits per second).
 With a packet size, L, of 1,000 bytes (8,000 bits) per packet, including both
header fields and data, the time needed to actually transmit the packet into
the 1 Gbps link is
 dtrans = L/R = 8000 bits 10 pow 9 bits/sec = 8 microseconds
 Figure 3.18(a) shows that with our stop-and-wait protocol, if the sender
begins sending the packet at t = 0, then at t = L/R = 8 microseconds, the last
bit enters the channel at the sender side.
 The packet then makes its 15-msec cross-country journey, with the last bit of
the packet emerging at the receiver at t = RTT/2 + L/R = 15.008 msec.
Transport Layer: 3-35
 Assuming ACK packets are extremely small (so that we can
ignore their transmission time) and that the receiver can send an
ACK as soon as the last bit of a data packet is received,
• the ACK emerges back at the sender at t = RTT + L/R = 30.008 msec.
• At this point, the sender can now transmit the next message.
• Thus, in 30.008 msec, the sender was sending for only 0.008 msec.
 If we define the utilization of the sender (or the channel) as the
fraction of time the sender is actually busy sending bits into the
channel, the analysis in Figure 3.18(a) shows that
• the stop-and-wait protocol has a rather dismal sender utilization, Usender,
of
• Usender = L/R / (RTT + L/R) = .008 / 30.008 = 0.00027
• That is, the sender was busy only 2.7 hundredths of one percent of the
time!
• Viewed another way, the sender was able to send only 1,000 bytes in
30.008 milliseconds.

Transport Layer: 3-36

 Pipelined protocols operation
pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged
packets
• range of sequence numbers must be increased
• buffering at sender and/or receiver

Transport Layer: 3-37

 Pipelining: increased utilization
sender receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R

first packet bit arrives

RTT last packet bit arrives, send ACK
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R
3-packet pipelining increases
utilization by a factor of 3!

U 3L / R .0024
sender = = = 0.00081
RTT + L / R 30.008

• If the sender is allowed to transmit 03 packets before having to wait

for acknowledgments, the utilization of the sender is essentially
tripled.
• Since the many in-transit sender-to-receiver packets can be visualized
as filling a pipeline, this technique is known as pipelining.
 Go-Back-N in action – Pipeline Protocol

In a Go-Back-N sender window (N=4) sender receiver

(GBN) protocol, 012345678 send pkt0
the sender is 012345678 send pkt1
send pkt2 receive pkt0, send ack0
allowed to transmit 012345678
receive pkt1, send ack1
012345678 send pkt3 Xloss
multiple packets
(wait)
(when available) receive pkt3, discard,
without waiting for 012345678 rcv ack0, send pkt4 (re)send ack1
an 012345678 rcv ack1, send pkt5 receive pkt4, discard,
acknowledgment, (re)send ack1
ignore duplicate ACK receive pkt5, discard,
but is constrained
(re)send ack1
to have no more pkt 2 timeout
than some 012345678 send pkt2
012345678 send pkt3
maximum 012345678 send pkt4 rcv pkt2, deliver, send ack2
allowable 012345678 send pkt5 rcv pkt3, deliver, send ack3
number, N, of rcv pkt4, deliver, send ack4
rcv pkt5, deliver, send ack5
unacknowledged
packets in the Transport Layer: 3-39

pipeline.
 Selective Repeat in action – Pipeline Protocol
When the sender window (N=4) sender receiver
window size and 012345678 send pkt0
bandwidth-delay 012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
product are both 012345678 send pkt3 Xloss receive pkt1, send ack1
large, many (wait)
receive pkt3, buffer,
packets can be 012345678 rcv ack0, send pkt4 send ack3
in the pipeline. 012345678 rcv ack1, send pkt5
receive pkt4, buffer,
A single packet record ack3 arrived send ack4
receive pkt5, buffer,
error can thus pkt 2 timeout send ack5
cause GBN to 012345678 send pkt2
(but not 3,4,5)
012345678
retransmit a 012345678 rcv pkt2; deliver pkt2,
pkt3, pkt4, pkt5; send ack2
large number of 012345678

packets, many
Q: what happens when ack2 arrives?
unnecessarily. Transport Layer
3.5 TCP: overview RFCs: 793,1122, 2018, 5681, 7323

 TCP is connection-oriented because before one application process can

begin to send data to another, the two processes must first “handshake”
with each other.
 Two processes must send some preliminary segments to each other to
establish the parameters of the ensuing data transfer.
• For example, client first sends a special TCP segment; the server responds with a second
special TCP segment; and finally the client responds again with a third special segment -
Three-way Handshake.
 As part of TCP connection establishment, both sides of the connection will
initialize many TCP state variables associated with the TCP connection.
 TCP protocol runs only in the end systems and not in the intermediate
network elements (e.g., routers and link-layer switches).
 The intermediate network elements do not maintain TCP connection state.
The intermediate routers are completely oblivious to TCP connections; they
see datagrams, not connections.
Transport Layer: 3-42
3.5 TCP: overview RFCs: 793,1122, 2018, 5681, 7323
 point-to-point:
• one sender, one receiver
 cumulative ACKs
 reliable, in-order byte steam:
 pipelining:
• no “message boundaries"
• TCP congestion and flow control
 full duplex data: set window size
• Bi-directional data flow in
same connection i.e. data can  connection-oriented:
flow between Processes A and • handshaking (exchange of control
B. messages) initializes sender,
• The maximum segment size receiver state before data
(MSS) : The maximum amount exchange
of data that can be grabbed
and placed in a segment is  flow controlled:
limited by maximum segment • TCP will ensure that a sender is not
size, overwhelming a receiver by sending
Transport Layer: 3-43
• typically 1460 bytes. packets faster than it can consume
 Multiplexing/demultiplexing
demultiplexing at receiver:
multiplexing at sender: use header info to deliver
handle data from multiple received segments to correct
sockets, add transport header socket
(later used for demultiplexing)

application

application P1 P2 application socket

P3 transport P4
process
transport network transport
network link network
link physical link
physical physical

Transport Layer: 3-44

• Multiplexing : The job of gathering data chunks at the source host from
different sockets, encapsulating each data chunk with header information to
create segments and passing the segments to the network layer.

• Demultiplexing : The job of delivering the data in a transport-layer segment to

the correct socket.
 TCP segment structure
• Source and destination port numbers
• Used for multiplexing/ demultiplexing data from/to upper-layer applications.
• The 32-bit sequence number field and the 32-bit acknowledgment number field
• Used by the TCP sender and receiver in implementing a reliable data transfer service.
32 bits

source port # dest port # segment seq #: counting

ACK: seq # of next expected sequence number bytes of data into bytestream
byte; A bit: this is an ACK (not segments!)
acknowledgement number
length (of TCP header) head not
len used C E UAP R S F receive window flow control: # bytes
Internet checksum checksum Urg data pointer receiver willing to accept

C, E: congestion notification options (variable length)

TCP options
Used when a sender and receiver negotiate the maximum
segment size (MSS) or as a window scaling factor for use application data sent by
in high-speed networks. data application into
(variable length) TCP socket
RST, SYN, FIN: connection
setup and tear down i.e.
connection management
Figure: Book Page 230 – 231
Transport Layer: 3-45
 TCP sequence numbers, ACKs
These fields are a critical part of outgoing segment from sender
source port # dest port #

TCP’s reliable data transfer service. sequence

number
acknowledgement
Sequence numbers: numberrwnd
checksum urg pointer
• The sequence number for a window size
segment is the byte stream N

“number” of first byte in

segment’s data sender sequence number space

Acknowledgements: sent sent, not- usable not

• The acknowledgment number ACKed yet ACKed
(“in-flight”)
but not usable
yet sent
that Host A puts in its segment
is the sequence number of the outgoing segment from receiver

next byte Host A is expecting

source port # dest port #
sequence
from Host B. A
number
acknowledgement
number rwnd
• cumulative ACK checksum urg pointer

Q: how receiver handles out-of-order Transport Layer: 3-46

segments
• A: TCP spec doesn’t say, - up to
implementor
 TCP sequence numbers, ACKs
Suppose, Host A initiates a Telnet session with Host B.
Host A initiates the session - client, and Host B - server.
The starting sequence numbers are 42 and 79 for the client and server.

Host A Host B

User types‘C’
Seq=42, ACK=79, data = ‘C’
host ACKs receipt of‘C’,
echoes back ‘C’
Seq=79, ACK=43, data = ‘C’
host ACKs receipt
of echoed ‘C’ The acknowledgment
Seq=43, ACK=80
number is the sequence
number of the next byte.
simple telnet scenario
Transport Layer: 3-47
 TCP Sender (simplified)
• There are 03 major events related to data transmission and retransmission in
the TCP sender:
• data received from application above;
• timer timeout; and
• ACK receipt.

1. event: data received from application 2. event: timeout

 TCP receives data from the application,  TCP responds to the timeout
event by retransmitting the
encapsulates the data in a segment, and segment that caused the
passes the segment to IP. timeout.
 Create segment with seq #  TCP restarts the timer
 seq # is byte-stream number of first data 3. event: ACK received
byte in segment  The arrival of an
 TCP starts the timer when the acknowledgment segment (ACK)
from the receiver.
segment is passed to IP.
• think of timer as for oldest unACKed  if ACK acknowledges previously
segment unACKed segments
Transport Layer: 3-48

• expiration interval: TimeOutInterval • update what is known to be ACKed

• start timer if there are still unACKed
segments
 TCP: retransmission scenarios
Host A Host B

• Suppose that this segment has

sequence number 92 and
Seq=92, 8 bytes of data
contains 8 bytes of data. After

timeout
sending this segment, Host A ACK=100
waits for a segment from B with X
acknowledgment number 100.
• Although the segment from A is
received at B, the Seq=92, 8 bytes of data

acknowledgment from B to A
gets lost. In this case, the ACK=100
timeout event occurs, and Host A
retransmits the same segment.
lost ACK scenario
Transport Layer: 3-49
 TCP: retransmission scenarios
• Host A sends two segments back to back. The first
Host A Host B
segment has sequence number 92 and 8 bytes of
data, and the second segment has sequence
number 100 and 20 bytes of data.
• SendBase=92
Suppose that both segments arrive intact at B, and
Seq=92, 8 bytes of data
B sends two separate acknowledgments for each

timeout
of these segments. Seq=100, 20 bytes of data

• The first of these acknowledgments has

ACK=100
acknowledgment number 100; the second has
ACK=120
acknowledgment number 120.
• Suppose now that neither of the acknowledgments Seq=92, 8
SendBase=100 bytes of data
arrives at Host A before the timeout. send cumulative
SendBase=120 ACK for 120
• When the timeout event occurs, Host A
ACK=120
resends the first segment with sequence
SendBase=120
number 92 and restarts the timer.
• As long as the ACK for the second segment premature timeout
arrives before the new timeout, the second
segment will not be retransmitted.
Transport Layer: 3-50
TCP: retransmission scenarios
Host A Host B
• In a third and final scenario, suppose Host A
sends the two segments, exactly as in the
second example.
Seq=92, 8 bytes of data
• The acknowledgment of the first segment is
Seq=100, 20 bytes of data
lost in the network, but just before the
ACK=100
X timeout event, Host A receives an
ACK=120 acknowledgment with acknowledgment
number 120.
• Host A therefore knows that Host B has
Seq=120, 15 bytes of data
received everything up through byte
119;
cumulative ACK covers • So Host A does not resend either of the
for earlier lost ACK two segments.
Transport Layer: 3-51
 TCP fast retransmit
• One of the problems with timeout-triggered retransmissions is that the
timeout period can be relatively long.
• When a segment is lost, this long timeout period forces the sender to delay
resending the lost packet, thereby increasing the end-to-end delay.
• Fortunately, the sender can often detect packet loss well before the timeout
event occurs by noting so-called duplicate ACKs.
Host A Host B
TCP fast retransmit
if sender receives 3 additional Seq=92
ACKs for same data (“triple Seq=1
, 8 byte
00, 20
s of da
ta
duplicate ACKs”), resend unACKed bytes
of data
X
segment with smallest seq #
 likely that unACKed segment =100
ACK
lost, so don’t wait for timeout
timeout
=100
ACK
=100
ACK
=100
Receipt of three duplicate ACKs ACK

indicates 3 segments received Seq=100, 20 bytes of data

after a missing segment – lost

segment is likely. So
retransmit!
Transport Layer: 3-52
TCP flow control
application
Q: What happens if network Application removing
process

layer delivers data faster data from TCP socket

buffers
than application layer TCP socket
removes data from socket receiver buffers

buffers?
TCP
code
Network layer
delivering IP datagram
payload into TCP
IP
socket buffers
code

from sender

receiver protocol stack

Transport Layer: 3-53

TCP flow control
application
Q: What happens if network Application removing
process

layer delivers data faster data from TCP socket

buffers
than application layer TCP socket
removes data from socket receiver buffers

buffers?
TCP
code
Network layer
delivering IP datagram
payload into TCP
IP
socket buffers
code

from sender

receiver protocol stack

Transport Layer: 3-54

TCP flow control
application
Q: What happens if network Application removing
process

layer delivers data faster data from TCP socket

buffers
than application layer TCP socket
removes data from socket receiver buffers

buffers?
TCP
code

receive window
flow control: # bytes
receiver willing to accept IP
code

from sender

receiver protocol stack

Transport Layer: 3-55

TCP flow control
application
Q: What happens if network Application removing
process

layer delivers data faster data from TCP socket

buffers
than application layer TCP socket
removes data from socket receiver buffers

buffers?
TCP
flow control code

receiver controls sender, so

sender won’t overflow IP
code
receiver’s buffer by
transmitting too much, too
fast from sender

receiver protocol stack

Transport Layer: 3-56

TCP flow control
 TCP receiver “advertises” free
buffer space in rwnd field in TCP to application process
header
• RcvBuffer size set via socket RcvBuffer buffered data
options (typical default is 4096 bytes)
rwnd free buffer space
• many operating systems autoadjust
RcvBuffer
TCP segment payloads
 sender limits amount of unACKed
(“in-flight”) data to received rwnd TCP receiver-side buffering
 guarantees receive buffer will not
overflow
Transport Layer: 3-57
TCP flow control
flow control: # bytes receiver willing to accept

 TCP receiver “advertises” free

buffer space in rwnd field in TCP
header
receive window
• RcvBuffer size set via socket
options (typical default is 4096 bytes)
• many operating systems autoadjust
RcvBuffer
 sender limits amount of unACKed
(“in-flight”) data to received rwnd
 guarantees receive buffer will not
TCP segment format
overflow
Transport Layer: 3-58
 TCP 3-way handshake
Server state
serverSocket = socket(AF_INET,SOCK_STREAM)
Client state [Link]((‘’,serverPort))
[Link](1)
clientSocket = socket(AF_INET, SOCK_STREAM) connectionSocket, addr = [Link]()
LISTEN
[Link]((serverName,serverPort)) LISTEN
choose init seq num, x
send TCP SYN msg
SYNSENT SYNbit=1, Seq=x
choose init seq num, y
send TCP SYNACK
msg, acking SYN SYN RCVD
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
received SYNACK(x)
ESTAB indicates server is live;
send ACK for SYNACK;
this segment may contain ACKbit=1, ACKnum=y+1
client-to-server data
received ACK(y)
indicates client is live
ESTAB

Transport Layer: 3-59

Closing a TCP connection
 client, server each close their side of connection
• send TCP segment with FIN bit = 1
 respond to received FIN with ACK
• on receiving FIN, ACK can be combined with own FIN
 simultaneous FIN exchanges can be handled

Transport Layer: 3-60

Closing a TCP connection

client state server state

ESTAB ESTAB
[Link]()
FIN_WAIT_1 can no longer FINbit=1, seq=x
send but can
receive data CLOSE_WAIT
ACKbit=1; ACKnum=x+1
can still
FIN_WAIT_2 wait for server send data
close

LAST_ACK
FINbit=1, seq=y
TIMED_WAIT can no longer
send data
ACKbit=1; ACKnum=y+1
timed wait
for 2*max CLOSED
segment lifetime

CLOSED

Transport Layer: 3-61

3.7 Principles of congestion control
Congestion:
 informally: “too many sources sending too much data too fast for
network to handle”
 manifestations:
• long delays (queueing in router buffers)
• packet loss (buffer overflow at routers)
 different from flow control! congestion
 a top-10 problem! control: too many
senders, sending too fast

flow control: one sender

too fast for one receiver
Transport Layer: 3-62
Approaches towards congestion control

End-end congestion control:

 no explicit feedback from
network
 congestion inferred from ACKs
data data
ACKs
observed loss, delay
 approach taken by TCP

Transport Layer: 3-63

Approaches towards congestion control

Network-assisted congestion
control: explicit congestion info

 routers provide direct feedback

to sending/receiving hosts with data data
ACKs
flows passing through congested ACKs

router
 may indicate congestion level or
explicitly set sending rate
 TCP ECN, ATM, DECbit protocols
Transport Layer: 3-64
TCP congestion control: AIMD
 approach: senders can increase sending rate until packet loss
(congestion) occurs, then decrease sending rate on loss event
Additive Increase Multiplicative Decrease
increase sending rate by 1 cut sending rate in half at
maximum segment size every each loss event
RTT until loss detected
TCP sender Sending rate

AIMD sawtooth
behavior: probing
for bandwidth

time Transport Layer: 3-65

TCP congestion control: details
sender sequence number space
cwnd TCP sending behavior:
 roughly: send cwnd bytes,
wait RTT for ACKS, then
send more bytes
last byte
available but cwnd
ACKed sent, but not- TCP rate ~
~ bytes/sec
yet ACKed not used RTT
(“in-flight”) last byte sent

 TCP sender limits transmission: LastByteSent- LastByteAcked < cwnd

 cwnd is dynamically adjusted in response to observed network
congestion (implementing TCP congestion control)
Transport Layer: 3-66
TCP slow start
Host A Host B
 when connection begins,
increase rate exponentially
until first loss event:
one segm
ent

RTT
• initially cwnd = 1 MSS two segm
ents
• double cwnd every RTT
• done by incrementing four segm
cwnd for every ACK ents

received initial rate is

 summary:
slow, but ramps up
exponentially fast time

Transport Layer: 3-67

TCP: from slow start to congestion avoidance
Q: when should the exponential
increase switch to linear?
X
A: when cwnd gets to 1/2 of its
value before timeout.

Implementation:
 variable ssthresh
 on loss event, ssthresh is set to
1/2 of cwnd just before loss event

* Check out the online interactive exercises for more examples: h ttp://[Link]/kurose_ross/interactive/
Transport Layer: 3-68
TCP Receiver: ACK generation [RFC 5681]
Event at receiver TCP receiver action
arrival of in-order segment with delayed ACK. Wait up to 500ms
expected seq #. All data up to for next segment. If no next segment,
expected seq # already ACKed send ACK

arrival of in-order segment with immediately send single cumulative

expected seq #. One other ACK, ACKing both in-order segments
segment has ACK pending

arrival of out-of-order segment immediately send duplicate ACK,

higher-than-expect seq. # . indicating seq. # of next expected byte
Gap detected

arrival of segment that immediate send ACK, provided that

partially or completely fills gap segment starts at lower end of gap

Transport Layer: 3-69

Questions????

Introduction 70