3150710 – Computer Networks

UNIT-3
TRANSPORT LAYER
✓
Syllabus
Loopi
ng Transport Layer: Introduction and transport
layer services, Multiplexing and
Demultiplexing, Connectionless transport
(UDP), Principles of reliable data transfer,
Connection-oriented transport (TCP),
Congestion control, TCP congestion control

2
✓ Loop
Outline
ing

• Introduction and Transport Layer

Services
• Multiplexing and Demultiplexing
• Connectionless transport (UDP)
• Principles of Reliable Data Transfer
• Connection oriented transport (TCP)
• Congestion control
The transport layer is responsible for
process-to-process delivery.
IP ADDRESSES VERSUS PORT NUMBERS
SOCKET ADDRESS
 TRANSPORT LAYER SERVICES AND PROTOCOLS
🞆 It provides logical applicatio

communication between running transport

n
network
data link
application processes on different physical

hosts.
🞆 A transport protocols run in end
systems.
○ Sender side: It breaks application
messages into segments, then
passes to network layer. applicatio

○ Receiver side: It reassembles transport

n
networ
k data
segments into messages, then link
physic
al

passes to application layer.

🞆 E.g. TCP and UDP
 TRANSPORT LAYER SERVICES AND PROTOCOLS – EXAMPLE
West Side

Applications Messages = Letters in envelops

Network Layer Protocol = postal service

(including mail persons)

East Side
Hosts(End Systems) = Houses

Processes = Cousins

Transport Layer Protocol = Ann & Bill

MULTIPLEXING AND DEMULTIPLEXING
MULTIPLEXING / DEMULTIPLEXING

Multiplexing at sender:
To handle data from multiple Demultiplexing at receiver:
sockets, add transport Use header information to
header (later used for deliver received segments to
demultiplexing) correct socket

application

application P1 P2 application socket

P3 transport P4
process
transport network transport
network link network
link physical link
physical physical
MULTIPLEXING / DEMULTIPLEXING
🞆 The most fundamental responsibility of UDP and TCP is to extend IP’s
delivery service between two end systems to a delivery service
between two processes running on the end systems.
🞆 Extending host-to-host delivery to process-to-process delivery is
called transport-layer multiplexing and demultiplexing.
🞆 Each transport-layer segment has a set of fields in the segment for this
purpose.
🞆 At the receiving end, the transport layer examines these fields to
identify the receiving socket and then directs the segment to that
socket.
🞆 This job of delivering the data in a transport-layer segment to the
correct socket is called demultiplexing.
🞆 The job of gathering data chunks at the source host from different
sockets, encapsulating each data chunk with header information (that
will later be used in demultiplexing) to create segments, and passing
the segments to the network layer is called multiplexing.
POSITION OF UDP, TCP, AND SCTP IN TCP/IP SUITE
 HOW DEMULTIPLEXING WORKS?

🞆A host PC receives 32 bits

IP datagrams. source port # dest port #

🞆 Each datagram has source IP
Other header fields
address and destination IP
address.
🞆 Each datagram carries one Application data
(message)
transport-layer segment.
🞆 Each segment has source and
destination port number.
TCP/UDP segment format
🞆 A host PC uses IP addresses &
port numbers to direct segment
to appropriate socket.
 CONNECTIONLESS DEMULTIPLEXING
🞆 Create socket with host-local port #:
DatagramSocket mySocket1 = new DatagramSocket(12534);
🞆 After creating datagram, must specify:
⚫Destination IP address
⚫Destination port #
🞆 When host receives UDP segment:
⚫It checks destination port # in segment and directs UDP
segment to socket with that port #.
🞆 IP datagrams with same destination port #, but different source
IP addresses and/or source port numbers will be directed to
same socket at destination.
 EXAMPLE: CONNECTIONLESS

DatagramSocket serverSocket =
DatagramSocket mySocket2 = new DatagramSocket(6428); DatagramSocket mySocket1 =
new DatagramSocket(9157); new DatagramSocket(5775);
applicati
application on application
P3 P1 P4
transpo
transport rt transport
networ
network k lin network
link k
physic link
physical al physical

source port: 6428 source port: 6428

dest port: 9157 dest port: 5775

source port: 9157 source port: 5775

dest port: 6428
dest port: 6428
 CONNECTION-ORIENTED DEMULTIPLEXING
🞆 TCP socket identified by 4-tuple:
⚫source IP address
⚫source port number
⚫destination IP address
⚫destination port number
🞆 When TCP segment arrives, receiver uses all four values to
direct(demultiplex) segment to appropriate socket.
🞆 Server host may support many simultaneous TCP sockets:
⚫each socket identified by its own 4-tuple.
🞆 Web servers have different socketsfor each
connecting client.
🞆 Persistent HTTP will have same socket per each request.
🞆 Non-persistent HTTP will have different socket for
each request.
 EXAMPLE: CONNECTION-ORIENTED
application
application P4 P5 P6 application
P3 P2 P3
transport
transport transport
network
network link network
link physical link
physical physical
server:
IP address B host:
host:
IP address C
IP address A
source IP,port: B,80
dest IP,port: A,9157 source IP,port: C,5775
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80 source IP,port: C,9157
dest IP,port: B,80
Three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets
CONNECTIONLESS TRANSPORT - UDP
🞆 User Datagram Protocol – Transport layer protocol.
🞆 It takes message from application process, attach source & dest.
port# for Multiplexing/Demultiplexing then pass to network
layer.
🞆 Making best effort to deliver the segment.
🞆 No handshaking between sender and receiver in
transport layer.
🞆 So, that UDP is connectionless protocol. E.g. DNS, SNMP, RIP
🞆 UDP used in streaming multimedia apps (loss tolerant, rate
sensitive).
 UDP
🞆 The User Datagram Protocol (UDP) is called a
connectionless, unreliable transport protocol.
🞆 It does not add anything to the services of IP except to provide
process-to-process communication instead of host-to-host
communication.
WELL-KNOWN PORTS USED WITH UDP
USER DATAGRAM FORMAT
UDP SEGMENT - HEADER
length (in bytes)
32 bits
source port # dest port #
length checksum

UDP
● No connection establishment
application
data (which can add delay)
(payload) ● Simple: no connection state at
sender and receiver
● Small header size
● No congestion control: UDP can
blast away as fast as desired
UDP segment format
 UDP - CHECKSUM
🞆 Checksum is used to detect errors in transmitted segment.
Sender:
🞆 Treat segment contents, including header fields, as sequence of
16-bit integers.
🞆 Checksum: addition (one ’ s complement pf sum)
of segment
contents.
🞆 Sender puts checksum value into UDP checksum field.
Receiver:
🞆 Compute checksum of received segment.
🞆 Check if computed checksum equals checksum field value:
✔ NO - error detected
 CHECKSUM - EXAMPLE
🞆 Add two 16-bit integers word
Sender Receiver
1110011001100110 1110011001100110
1101010101010101 1101010101010101
wraparound 1 1011101110111011 1 1011101110111
+ 1 0 1 1+ 1
sum 1011101110111100 1011101110111100
checksum 0100010001000011 0100010001000011
1111111111111111
If one of the bits is a 0, then we can
say that error introduced into
packet
Note: when adding numbers, a carryout from
the most significant bit needs to be added to the result
CHECKSUM CALCULATION OF A SIMPLE UDP
USER DATAGRAM

Here are the ASCII values for each letter in the word
"TESTING":
T: 84 E: 69 S: 83 T: 84 I: 73 N: 78 G: 71
PRINCIPLES OF RELIABLE
DATA TRANSFER
PRINCIPLES OF RELIABLE DATA TRANSFER

Characteristics of unreliable channel will determine complexity of

reliable data transfer protocol (rdt)
UNRELIABLE CHANNEL CHARACTERISTICS
🞆 Packet Errors:
⚫packet content modified
⚫Assumption: either no errors or detectable.
🞆 Packet loss:
⚫Can packet be dropped
🞆 Packet duplication:
⚫Can packets be duplicated.
🞆 Reordering of packets
⚫Is channel FIFO?
🞆 Internet: Errors, Loss, Duplication, non-FIFO
RELIABLE DATA TRANSFER(RDT)
rdt_send(): called from above layer, deliver_data(): called by
(e.g., by application layer). rdt to deliver data to upper layer
Passed data to receiver

sender receiver
side side

udt_send(): called by rdt, to rdt_rcv(): called when packet

transfer packet over arrives on receiver side of channel
unreliable channel to receiver
 RELIABLE DATA TRANSFER – CONT…
● In reliable data transfer (RDT) protocols, ensuring that data is
correctly transmitted between a sender and receiver is essential,
particularly over unreliable networks.
● The use of finite state machines (FSM) to model both the sender
and receiver helps clarify the operations, state transitions, and
handling of events such as acknowledgments, timeouts, and errors.
Unidirectional Data Transfer:
● Data only flows in one direction (from Sender to Receiver), while
control information (e.g., acknowledgments or negative
acknowledgments) can flow in both directions.
Finite State Machine (FSM):
● Sender and Receiver are modeled as FSMs.
● Each machine can only be in one state at a time.
● Events (such as receiving a packet, a timeout, or an
acknowledgment) cause state transitions.
● Actions (such as sending a packet or retransmitting) occur during
transitions.
 RELIABLE DATA TRANSFER – CONT…
Key Events Causing State Transitions:
● Packet Arrival (Data): The receiver gets a new data packet.
● Timeout: The sender doesn't receive an acknowledgment within a
specified time.
● ACK (Acknowledgment): The receiver sends back an
acknowledgment after receiving data.
● NAK (Negative Acknowledgment): The receiver indicates that the
data was corrupted or missing.
Actions Taken on State Transition:
● Send Data: The sender transmits a data packet.
● Send ACK/NAK: The receiver sends an acknowledgment or a
negative acknowledgment.
● Retransmission: The sender retransmits the packet if it times out or
receives a NAK.
RDT 1.0
🞆 Reliable transfer over a reliable channel
🞆 Underlying channel perfectly reliable channel
⚫no bit errors
⚫no loss of packets
🞆 Separate FSMs for sender & receiver:
⚫Sender sends data into underlying channel
⚫Receiver reads data from underlying channel

Wait for rdt_send(data) Wait for rdt_rcv(packet)

call from call from
extract (packet,data)
above packet = make_pkt(data) below
deliver_data(data)
udt_send(packet)

sender receiver
 RDT 2.0 – CHANNEL WITH BIT ERRORS
🞆 There is no packet loss
🞆 Underlying channel may flip bits in packet.
⚫ Checksum to detect bit errors.
🞆 Question: How do we recover from errors?
⚫ Acknowledgements (ACKs): receiverexplicitly tells
sender that packet received OK.
⚫ Negative acknowledgements (NAKs): receiver explicitly tells sender
that packet had errors.
⚫ Sender retransmits packet on receipt of NAK.
🞆 New mechanisms in rdt 2.0 (beyond rdt 1.0):
⚫ Error detection
⚫ Feedback: control messages(ACK,NAK) from receiverto
sender
⚫ Retransmission: Error in received packet,
retransmitted by the sender
🞆 It is known as stop-and-wait protocol.
 RDT2.0 HAS A FATAL FLAW!
What happens if ACK/NAK
corrupted?
🞆 Sender doesn’t know what
happened at receiver!
🞆 Can’t just retransmit: possible
duplicate
Handling duplicates:
🞆 Sender retransmits current pkt if
ACK/NAK corrupted
🞆 Sender adds sequence
stop and wait number to each pkt
sender sends one packet, 🞆 Receiver discards (doesn’t deliver
then waits for receiver up) duplicate pkt
response
RDT 2.0 – WITH NO ERROR
rdt_send(data)

snkpkt = make_pkt(data, checksum)

udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Wait for isNAK(rcvpkt)
Wait for
rdt_rcv(rcvpkt) &&
call from ACK
above udt_send(sndpkt) corrupt(rcvpkt)
or
NAK udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
Λ call from
below
Sender
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Receiver
RDT 2.0 – WITH ERROR
rdt_send(data)
snkpkt = make_pkt(data, checksum) Receiver
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Wait for Wait for isNAK(rcvpkt)
rdt_rcv(rcvpkt) &&
call from ACK udt_send(sndpkt)
above or corrupt(rcvpkt)
NAK udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
Λ call from
below
Sender
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
RDT 2.0: TYPICAL BEHAVIOR
Typical sequence in sender FSM:
“wait for call”
rdt_send(data)

#42
udt_send(data)
“wait for Ack/Nack”
udt_send(data) udt_send(NACK)
...
udt_send(data) udt_send(NACK)
udt_send(data) udt_send(ACK)
“wait for call”

Claim A: There is at most one packet in transit.

RDT 2.1 - HANDLED ACKS/NAKS
Sender:
🞆 Sequence # added to packet
🞆 Two sequence #’s (0,1) will suffix
🞆 It must check if received ACK/NAK corrupted or not
🞆 It can be twice as many states
⚫State must “remember” whether “expected” packet should
have sequence # of 0 or 1
Receiver:
🞆 It must check if received packet is duplicate or not
🞆 State indicates whether 0 or 1 is expected packet sequence #
🞆 Receiver can not know if its last ACK/NAK received OK at
sender
RDT 2.1 - GARBLED ACK/NACK
What to do?
What happens if
ACK/NACK corrupted? ❒ Assume it was a NACK -
retransmit, but this might cause
🞆 sender doesn’t know what
retransmission of correctly
happened at receiver!
received pkt! Duplicate.
🞆 If ACK was corrupt:
❒ Assume it was an ACK -
⚫Data was delivered continue to next data, but this
⚫Needs to return to “wait for might cause the data to never
call” reach the receiver! Missing.
🞆 If NACK was corrupt: ❒ Solution: sender ACKs/NACKs
⚫Data was not delivered. receiver’s ACK/NACK.
⚫Needs to resend data. What if sender ACK/NACK
corrupted?
RDT 2.1 - GARBLED ACK/NACK

Handling duplicates:
🞆 Sender adds sequence number to each packet
🞆 Sender retransmits current packet if ACK/NACK garbled
receiver discards (doesn’t deliver up) duplicate packet

Stop and wait

Sender sends one packet, then waits for

receiver response
RDT 2.1 IN ACTION
sender receiver send receiv
er er
pkt pkt
send send
pkt0 rcv pkt0 pkt0 rcv pkt0
ACK ACK
send send
rcv rcv
pkt ACK0 pkt ACK0
ACK0 ACK0
send rcv send X (corruptedr)cv
send
pkt1 NAK send
pkt1 pkt1
ACK1 pkt1 NAK1
rcv rcv
send AC resend pkt
ACK1 NAK1
pkt0 rcv pkt0 pkt1 rcv pkt1
K ACK
send send
ACK0 ACK1
pkt
a) operation with no b) packet
corruption ACK corrupted
RDT 2.1 IN ACTION (CONT)
sender receiver
pk
send
t rcv pkt0
pkt0
AC
(corrupted) K send
rcv X ACK0
resend pkt
ACK0
pkt0 rcv
AC send
pkt0
K ACK0
rcv
send
ACK0
pkt1 pkt rcv pkt1
AC send
K ACK1
c) ACK
corrupted
RDT 2.1 - SENDER, HANDLED ACKS/NAKS
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for Wait for
isNAK(rcvpkt) )
call 0 from ACK
or udt_send(sndpkt)
above
rdt_rcv(rcvpkt) NAK 0
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)
Λ
Λ
Wait for Wait for
ACK call 1 from
rdt_rcv(rcvpkt) && or above
( corrupt(rcvpkt) || NAK 1
isNAK(rcvpkt) ) rdt_send(data)

udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

udt_send(sndpkt)
 RDT 2.1 - RECEIVER, HANDLED ACKS/NAKS
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
Wait for Wait for
rdt_rcv(rcvpkt) && 0 from 1 from rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && below below not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
 RDT2.2: A NACK-FREE PROTOCOL
● Same functionality as rdt2.1,
using ACKs only sende
rFSM
● Instead of NACK, receiver
sends ACK for last pkt
received OK
○ receiver must explicitly
include seq # of pkt
being ACKed
● Duplicate ACK at sender
results in same action as !
NACK: retransmit current
pkt
 RDT 2.2 – SENDER AND RECEIVER
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for Wait for
ACK isACK(rcvpkt,1) )
call 0 from
above 0 udt_send(sndpkt)
sender FSM
fragment rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || Λ
has_seq1(rcvpkt)) Wait for receiver FSM
0 from
udt_send(sndpkt) below fragment
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK,1, chksum)
udt_send(sndpkt)
RDT 2.2 IN ACTION
sender receiver send receiv
er er
pkt0 pkt0
send send
pkt0 rcv pkt0 pkt0 rcv pkt0
ACK0 ACK
send send
rcv rcv ACK0 0
pkt1 ACK0 ACK0
ACK0 send
send rcv pkt1 pkt1 X (corrupterdcv)
send
pkt1 ACK send
pkt1
ACK1 pkt1
0 ACK0
rcv rcv
send
ACK1 ACK resend
ACK0
pkt0 rcv pkt0 pkt1 pkt1 rcv pkt1
1 send send
ACK
ACK0 1 ACK1
pkt0
a) operation with no b) packet
corruptionACK corrupted
0
RDT 2.2 IN ACTION (CONT)
sender receiver

pkt
send
0
pkt0 rcv
ACK0 send
(corrupted)pkt0
rcv X ACK0
resend pkt0
ACK0
pkt0 rcv
ACK send
pkt0
0 ACK0
rcv
send
ACK0
pkt1 pkt1 rcv pkt1
send
ACK
1 ACK1
c) ACK
corrupted
 RDT 3.0: CHANNEL WITH ERROR AND LOSS
🞆 Underlying channel can also lose packets
(data, ACKs).
⚫Even checksum, sequence #, ACKs,
retransmissions will not enough help.
🞆 Sender waits “reasonable” amount of time for ACK.
🞆 It retransmits if no ACK received in this time.
🞆 If packet(or ACK) just delayed (not lost):
⚫Retransmission will be duplicate, but sequence #’s already
handled it.
🞆 Receiver must specify sequence # of packet
being ACKed.
🞆 It requires countdown timer.
CHANNEL UC 3.0
🞆 FIFO:
⚫Data packets and Ack packets are delivered in order.
🞆 Errors and Loss:
⚫Data and ACK packets might get corrupt or lost
🞆 No duplication: but can handle it!
🞆 Liveness:
⚫If continuously sending packets, eventually, an
uncorrupted packet received.
RDT3.0: CHANNELS WITH ERRORS AND
LOSS
New assumption: underlying Approach: sender waits
channel can also lose packets “reasonable” amount of
(data or ACKs) time for ACK
⚫ checksum, seq. #, 🞆 retransmits if no ACK
ACKs, retransmissions received in this time
will be of help, but not
enough 🞆 if pkt (or ACK) just delayed
(not lost):
Q: how to deal with
⚫ retransmission will be
loss?
duplicate, but use of seq.
⚫ sender waits until
#’s already handles this
certain data or ACK
lost, then retransmits ⚫ receiver must specify seq #
⚫ feasible? of pkt being ACKed
🞆 requires countdown timer
 RDT 3.0: ALTERNATING-BIT PROTOCOL

sender receiver sender receiver

send pkt0 send pkt0
pkt0 rcv pkt0 pkt0 rcv pkt0
ack0 send ack0 send
rcv ack0 rcv
ack0 ack0 pkt1 ack0
send pkt1 rcv pkt1 send X
pkt1 ack1
send pkt1 los
rcv ack1 s
pkt0
ack1 rcv pkt0 timeout
send ack0 send resend pkt1
pkt0 ack0 pkt1 rcv pkt1
ack1 send
rcv ack1
pkt0
ack1 rcv pkt0
(a) no
send ack send
loss ack0
pkt0 0

(b) packet
loss
 RDT 3.0 – CONT…
sender receiv
receiver send er
sender pkt0
pkt0
pkt0 rcv pkt0
send pkt0 ack0 send
rcv pkt0
send rcv
ack0 ack0 ack0
rcv ack0
send rcv pkt1
ack0 pkt1 pkt1
send rcv pkt1 send
pkt1
ack1 ack1
pkt1 send ack1
X
los ack1 timeout
s pkt1
timeout resend rcv
resend pkt1 pkt1 pkt0 (detect
pkt1
rcv pkt1 send ack1
duplicate
pkt1 ack1
ack1 (detect rcv
duplicate) ack0 rcv pkt0
rcv ack1
pkt0 send ack1 pkt0 send ack0
ack1 send
rcv pkt0 rcv pkt0
send ack0 send pkt0 ack0
(detect
pkt0 ack0 rcv duplicate
ack1 send ack0
(c) ACK (d) premature
send timeout/ delayed
loss ACK pkt0
SLIDING WINDOW CONCEPT
Core Concepts of Sliding Window:
🞆 Window Size:
⚫ A sliding window represents the range of sequence
numbers that are allowed to be sent (for the sender) or
received (for the receiver) without waiting for an
acknowledgment.
⚫ The window size determines the number of
unacknowledged packets that the sender can transmit
before it must stop and wait for ACKs.
⚫ Both sender and receiver maintain their own sliding
windows.
🞆 Send Window:
⚫ This is the range of sequence numbers that the sender is
allowed to transmit.
⚫ Once packets are acknowledged, the window "slides"
forward, allowing the sender to transmit more packets.
🞆 Receive Window:
⚫ This is the range of sequence numbers that the receiver is
willing to accept at any point in time.
⚫ It ensures that the receiver doesn’t get overwhelmed by
too many packets too quickly.
🞆 ACKs and Cumulative ACKs:
⚫ For each packet received without errors, the receiver sends
an acknowledgment (ACK).
⚫ In cumulative acknowledgment, the receiver
acknowledges the highest in-sequence packet number
received correctly.
⚫ This implies that all packets up to the acknowledged one
have been received without issues.
🞆 Sliding the Window:
⚫ Once a packet is acknowledged, both the sender and
receiver slide their respective windows forward to allow
for new transmissions.
🞆 Types of Sliding Window Protocols:
1) Go-Back-N:
■ The sender can send several packets specified by the
window size, but if a packet is lost or an error occurs,
the receiver ignores all subsequent packets and sends a
NAK for the lost packet.
■ The sender, upon receiving the NAK, goes back and
retransmits the lost packet and all subsequent packets,
even if they were received correctly by the receiver.
2) Selective Repeat:
■ Instead of retransmitting all subsequent packets after a
lost one (like in Go-Back-N), only the lost packet is
retransmitted.
■ The receiver buffers the correctly received packets
until the lost one is received, after which it delivers
them in sequence to the application layer.
■ This improves efficiency, especially in networks with a
high error rate.
🞆 Sliding Window Key Parameters:
⚫ Window Size: The number of unacknowledged packets
that can be sent.
⚫ Sequence Numbers: The range of numbers used to
identify each packet.
⚫ Acknowledgment Number: The sequence number of the
next expected packet.
⚫ Timeout: If the sender doesn’t receive an
acknowledgment within a certain time, it retransmits the
packet.
Example of How Sliding Window Works:
Scenario:
🞆 Window Size = 4
🞆 Packets to send: P1, P2, P3, P4, P5, P6, P7, P8
🞆 Sender Side:
⚫ The sender transmits P1, P2, P3, P4 (as allowed by the
window size of 4).
⚫ The receiver successfully receives P1, P2, but P3 is lost,
and P4 is received.
⚫ The receiver sends an ACK for P2 (cumulative
acknowledgment), meaning packets up to P2 have been
received correctly.
⚫ The sender receives this ACK and slides its window to
allow for sending P5 and P6 but retransmits P3 due to the
missing acknowledgment.
🞆 Receiver Side:
⚫ The receiver gets P1, P2, but P3 is lost. It stores P4 in its
buffer and waits for P3 to be retransmitted.
⚫ Once P3 is retransmitted, it delivers the packets in order
(P3, then P4) to the application layer.
⚫ It then sends an ACK for P4 to the sender.
Advantages of Sliding Window:
🞆 Higher Efficiency: The sender doesn't need to stop and wait
after sending each packet. Multiple packets can be sent before
needing an ACK.
🞆 Error Handling: If an error occurs, retransmissions are
controlled by either retransmitting all subsequent packets (Go-
Back-N) or only the erroneous packets (Selective Repeat).
🞆 Flow Control: It prevents the sender from overwhelming the
receiver with more packets than it can handle.
Sliding window
PIPELINED PROTOCOL:
Go-back-N Protocol &
Selective Repeat Protocol
PIPELINED PROTOCOL
🞆 It's a technique in which multiple requests are written out to a
single socket without waiting for the corresponding responses
(acknowledged).
⚫No. of Packets(request) must be increased.
⚫Data or Packet should be buffered at sender and/or receiver.

🞆 Two generic forms of pipelined protocols:

1. Go-back-N
2. Selective Repeat
GO-BACK-N PROTOCOL
🞆 Sender can have up to N unacked packets in pipeline.
🞆 Receiver only sends cumulative ACK. It doesn’t
ACK packet if there’s a gap.
🞆 Sender has timer for oldest unacked packet.

🞆 When timer expires, retransmit all unacked

packets.
🞆 Sender send a number of frames specified by a window
size even without receiving an ACK packet from the
receiver.
GO-BACK-N PROTOCOL (CONT…)
🞆 Receiver keeps track of the sequence no. of the next frame it expects
to receive, and sends that number with every ACK it sends.
🞆 Receiver will discard any frame that does not have the exact
sequence number it expects.
⚫Either a duplicate frame it already ACKed
OR
⚫An out-of-order frame it expects to receive later
🞆 Receiver will resend an ACK for the last correct in-order frame.
🞆 Once the sender has sent all of the frames in its window. It will
detect that all of the frames since the first lost frame are outstanding.
🞆 Then go back to the sequence number of the last ACK it received
from receiver.
🞆 Go-back-N protocol also known as sliding window protocol.
ACKNOWLEDGEMENT
RECEIVER WINDOW SIZE = 1
WITHOUT SEQUENCE NUMBER
WITH SEQUENCE NUMBER
 GO-BACK-N PROTOCOL WORKS
Sender window (N=4)
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
receive pkt1, send ack1
012345678 send pkt3 Xlos
(wait) s
receive pkt3, discard,
012345678 rcv ack0, send pkt4 (re)send ack1
0 12 3 4 5678 rcv ack1, send pkt5 receive pkt4, discard,
(re)send ack1
ignore duplicate ACK
receive pkt5, discard,
pkt 2 timeout (re)send ack1

01 2345 678 send pkt2

rcv pkt2, deliver, send ack2
01 2345 678 send pkt3
01 2345 678 send pkt4 rcv pkt3, deliver, send ack3
01 2345 678 send pkt5 rcv pkt4, deliver, send ack4
rcv pkt5, deliver, send ack5
SELECTIVE REPEAT
🞆A sender can have up to N
unACKed packets in pipeline.
🞆Receiver sends individual ACK for each
packet.
🞆Sender maintains timer for each unACKed
packet.
🞆When timer expires, retransmit only that
unACKed packet.
🞆 Selective Repeat attempts to retransmit only those packets
that are actually lost due to errors.
🞆 Receiver must be able to accept packets out of order.
🞆 Since receiver must release packets to higher layer in order,
the receiver must be able to buffer some packets.
🞆 The receiver acknowledges every good packet, packets that
are not ACKed before a time-out are assumed lost or in
error.
🞆 This approach must be used to be sure that every
packet is eventually received.
🞆 An explicit NAK (selective reject) can request
retransmission of just one packet.
 SELECTIVE REPEAT WORKS
Sender window (N=4) sender receiver
0123 45678 send pkt0
0123 45678 send pkt1
0123 45678 send pkt2 receive pkt0, send ack0
receive pkt1, send ack1
0123 45678 send pkt3 Xloss
(wait)
receive pkt3, buffer,
0 1234 5678 rcv ack0, send pkt4 send ack3
01 2345 678 rcv ack1, send pkt5 receive pkt4, buffer,
send ack4
record ack3 arrived
receive pkt5, buffer,
pkt 2 timeout send ack5
01 2345 678
send pkt2
01 2345 678
01 2345 678 record ack4 arrived rcv pkt2;
record ack5 arrived
01 2345 678 deliver pkt2,pkt3, pkt4, pkt5;
Q: what happens when ack2 arrives? send ack2
 TCP
(TRANSMISSION CONTROL
PROTOCOL)
TCP (TRANSMISSION CONTROL PROTOCOL)

● TCP is a connection - oriented protocol.

● It creates a virtual connection between two TCPs to send
data.
● In addition, TCP uses flow and error control mechanisms
at the transport level.
WELL-KNOWN PORTS USED BY TCP
SENDING AND RECEIVING BUFFERS & TCP SEGMENTS
🞆 The bytes of data being transferred in each connection are
numbered by TCP.
🞆 The numbering starts with a randomly generated number.
🞆 The value in the sequence number field of a segment defines
the number of the first data byte contained in that segment.
🞆 The value of the acknowledgment field in a segment defines
the number of the next byte a party expects to receive.
🞆 The acknowledgment number is cumulative.
The following shows the sequence number for each segment:
IANA RANGES
CONTROL FIELD & DESCRIPTION OF FLAGS
TCP CONNECTION ESTABLISHMENT USING THREE-WAY HANDSHAKING
(CONNECTION ORIENTED)

● A SYN segment cannot carry data, but it consumes one sequence number.
● A SYN + ACK segment cannot carry data, but does consume one sequence
number.
● An ACK segment, if carrying no data, consumes no sequence number.
DATA TRANSFER
 CONNECTION TERMINATION USING THREE-WAY
HANDSHAKING

🞆 The FIN segment consumes one sequence number if it does not carry data.
🞆 The FIN + ACK segment consumes one sequence number if it does not
carry data.
TCP SEGMENT FORMAT

🞆 TCP Header Size= Min 20 to Max 60 Bytes

(i.e. 20 Bytes = 20 x 8 = 160 Bits)
 TCP SEGMENT STRUCTURE
32 bits
URG: urgent data counting
(generally not used) by bytes
Source Port # Destination Port #
ACK: ACK # of data
Sequence Number
valid (not segments)
Acknowledgement Number
PSH: push data now HLEN Reser.
Window Size
(generally not used) # bytes
Checksum Urg data pointer
receiver
RST, SYN, FIN: willing
Options (variable length)
connection establish to accept
(setup, teardown
commands)
Application
Internet data
checksum (variable length)
(as in UDP)
TCP SEGMENT – CONT…
🞆 The unit of transmission in TCP is called segments.
🞆 The header includes source and destination port numbers,
which are used for multiplexing/demultiplexing data
from/to upper-layer applications.
🞆 The 32-bit sequence number field and the 32-bit
acknowledgment number field are used by the TCP sender
and receiver in implementing a reliable data transfer
service.
🞆 The sequence number for a segment is the byte-stream
number of the first byte in the segment.
🞆 The acknowledgment number is the sequence number of the
next byte a Host is expecting from another Host.
TCP SEGMENT – CONT…
🞆 The 4-bit header length field specifies the length of the
TCP header in 32-bit words. The TCP header can be of
variable length due to the TCP options field.
🞆 The 16-bit receive window field is used for flow control. It
is used to indicate the number of bytes that a receiver is
willing to accept.
🞆 The 16-bit checksum field is used for error checking of the
header and data.
🞆 Unused 6 bits are reserved for future use and should be sent
to zero.
🞆 Urgent Pointer is used in combining with the URG control
bit for priority data transfer. This field contains the
sequence number of the last byte of urgent data.
TCP SEGMENT – CONT…
🞆 Data: The bytes of data being sent in the segment.
🞆 URG (1 bit): indicates that the Urgent pointer field is
significant.
🞆 ACK (1 bit): indicates that the Acknowledgment field is
significant.
🞆 PSH (1 bit): Push function. Asks to push the buffered data to the
receiving application.
🞆 RST (1 bit): Reset the connection.
🞆 SYN (1 bit): Synchronize sequence numbers. Only the first
packet sent from each end should have this flag set. Some other
flags and fields change meaning based on this flag, and some are
only valid for when it is set, and others when it is clear.
🞆 FIN (1 bit): No more data from sender.
 FLOW CONTROL &
CONGESTION CONTROL
FLOW CONTROL
🞆 Flow control is the process of managing the rate of data
transmission between two nodes to prevent a fast sender from
overwhelming a slow receiver.
🞆 It prevent receiver from becoming overloaded.
🞆 Receiver advertises a window rwnd(receiver window) with
each acknowledgement.
🞆 Window:
⚫Closed (by sender) when data is sent and ack’d
⚫Opened (by receiver) when data is read
🞆 The size of this window can be the performance limit.
CONGESTION CONTROL
🞆 Too many sources sending too much data too fast for network
to handle.
🞆 When a connection is established, a suitable window size
has to be chosen.
🞆 The receiver can specify a window based on its buffer size.
🞆 If the sender sticks to this window size, problems will not
occur due to buffer overflow at the receiving end, but they
may still occur due to internal congestion within the
network.
EFFECTS OF CONGESTION

🞆 Delay Increase
⚫If Delay Increases, retransmission occurs, making
situation worse.
🞆 Performance Decrease
CONGESTION CONTROL – CONT…

● The diagram represents

two scenarios of
congestion control in a
network, modeled using
a water flow analogy.
● Here, the "tap"
represents the sender
adjusting the
transmission rate, and
the "network" is
depicted as a pipe
through which data
flows to the receiver.
CONGESTION CONTROL – CONT…
(a)Small-capacity receiver:
● In this scenario, the
receiver has a small
capacity (depicted as a
small bucket).
● The "tap" controls the
rate at which water (data)
flows into the network.
● Key idea: Since the
receiver's capacity is
small, the transmission
rate must be adjusted
accordingly to prevent
overflow or loss of data.
● If the transmission rate is too high, the receiver won’t be able to process
the incoming data quickly enough, leading to congestion at the receiver
end.
● Here, congestion control must ensure that the sender reduces the
transmission rate to avoid overwhelming the small-capacity receiver.
CONGESTION CONTROL – CONT…
(b)Large-capacity receiver with
internal congestion:
● This example shows a receiver
with a large capacity (large
bucket).
● The internal part of the network
(depicted as a narrow pipe)
introduces congestion before the
data reaches the receiver.
● Key idea: Even though the
receiver has a large capacity, the
network itself might have
limitations (internal bottleneck),
leading to internal congestion.
● If the sender increases the transmission rate, congestion may occur within
the network, even though the receiver can handle more data.
● Congestion control mechanisms, such as TCP, need to account for not just
the receiver’s capacity but also the overall network condition to avoid
congesting the path.
CONGESTION CONTROL – CONT…
Congestion Control in the
Diagram:
● Scenario (a) focuses on
flow control: The sender
adjusts the rate to avoid
overwhelming a small-
capacity receiver.
● Scenario (b) focuses on
network congestion:
Even with a large
receiver capacity, the
network’s internal
congestion must be
managed by adjusting
the transmission rate at
the sender side.
CONGESTION CONTROL – CONT…

In real-world TCP, mechanisms like Slow Start and Congestion

Avoidance are used to adapt the sender’s transmission rate to prevent
either receiver overflow or network congestion.
CAUSES/COSTS OF CONGESTION:
SCENARIO 1
🞆 Two senders, Two receivers
🞆 One router, Infinite buffers
🞆 No retransmission
original data: λin throughput: λout

Host A unlimited shared output

link buffers

Host B
CAUSES/COSTS OF CONGESTION:
SCENARIO 2
🞆 One router, finite buffers
🞆 Sender retransmission of timed-out packet
▪ application-layer input = application-layer output: λ in= λout

▪ transport-layer input includes retransmissions : λ’ in >= λin

λin : original data
λout
λ'in: original data, plus
retransmitted data

Host A

Host B finite shared output

link buffers
🞆 Idealization: Perfect knowledge about buffer space
🞆 Sender sends only when router buffers available

λin : original data

copy λ out
λ'in: original data, plus
retransmitted data

Host A free buffer space!

Host B finite shared output

link buffers
🞆 Idealization: Known loss
🞆 Packets can be lost, dropped at router due to full buffers
🞆 Sender only resends if packet known to be lost

λin : original data

copy λout
λ'in: original data, plus
retransmitted data

Host A
no buffer space!

Host B
🞆 Realistic: duplicate packets
🞆 Packets can be lost, dropped at router due to full buffers
🞆 Sender times out prematurely, sending two copies, both of
which are delivered

λ
in
cop
timeo λout
ut
y
λ'in

Host A free buffer space!

Host B
 APPROACHES TOWARDS CONGESTION
CONTROL
🞆 Two broad approaches towards congestion control
1. End to End congestion control
🞆 No explicit feedback from network
🞆 Congestion inferred from end-system observed loss,
delay
🞆 Approach taken by TCP
2. Network-assisted congestion control
🞆 Routers provide feedback to end systems
🞆 Single bit indicating congestion (SNA, DECbit,
TCP/IP ECN, ATM)
🞆 Explicit rate for sender to send
 TCP SLOW START
🞆 An algorithm which balances
the speed of a network
connection.
🞆 TCP slow start is one of the
first steps in the congestion
control process.
🞆 It balances the amount of data a
sender can transmit (known as
the congestion window) with the
amount of data the receiver can
accept (known as receiver
window).
TCP SLOW START – CONT…
🞆 Slow start gradually increases the amount of data transmitted
until it finds the network’s maximum carrying capacity.
🞆 A sender communicate to a receiver. Initial packet contains a
small congestion window, which is determined based on the
sender’s maximum window.
🞆 A receiver acknowledges the packet and responds with its
own window size.
🞆 If the receiver fails to respond, the sender knows not to
continue sending data.
🞆 After receiving the acknowledgement, the sender
increases the next packet’s window size.
🞆 The window size gradually increases until the receiver can no
longer acknowledge each packet, or until either the sender or
the receiver’s window limit is reached.
Thank you……

107