Chapter 3

Transport Layer

Computer Networking: A
Top-Down Approach
8th edition
Jim Kurose, Keith Ross
Pearson, 2020
Transport Layer: 3-1
Transport services and protocols
application
transport

▪ provide logical communication mobile network

network
data link
physical
between application processes national or global ISP

running on different hosts

▪ transport protocols actions in end
systems: local or
• sender: breaks application messages regional ISP

into segments, passes to network layer home network content

• receiver: reassembles segments into provider
network datacenter
messages, passes to application layer application
transport
network
network

▪ two transport protocols available to data link

physical

Internet applications enterprise

network
• TCP, UDP
Transport Layer: 3-2
Transport vs. network layer services and protocols
household analogy:
12 kids in Ann’s house sending
letters to 12 kids in Bill’s
house:
▪ hosts = houses
▪ processes = kids
▪ app messages = letters in
envelopes
▪ transport protocol = Ann and Bill
who demux to in-house siblings
▪ network-layer protocol = postal
service

Transport Layer: 3-3

Transport vs. network layer services and protocols
household analogy:
▪transport layer:
12 kids in Ann’s house sending
communication between letters to 12 kids in Bill’s
processes house:
• relies on, enhances, network ▪ hosts = houses
layer services ▪ processes = kids
▪ app messages = letters in
envelopes
▪network layer: ▪ transport protocol = Ann and Bill
communication between who demux to in-house siblings
hosts ▪ network-layer protocol = postal
service

Transport Layer: 3-4

Transport Layer Actions

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

link ▪ passes segment to IP link

physical physical

Transport Layer: 3-5

Transport Layer Actions

Receiver:
application ▪ receives segment from IP application
▪ checks header values
transport
app. msg ▪ extracts application-layer transport
message
network (IP) network (IP)
▪ demultiplexes message up
link to application via socket link

physical physical
Th app. msg

Transport Layer: 3-6

Two principal Internet transport protocols
application
transport

▪ TCP: Transmission Control Protocol mobile network

network
data link
physical
• reliable, in-order delivery national or global ISP

• congestion control
• flow control
• connection setup
local or
▪ UDP: User Datagram Protocol regional ISP

• unreliable, unordered delivery home network content

• no-frills extension of “best-effort” IP provider
network datacenter
application
network
▪ services not available: transport
network
data link

• delay guarantees physical

• bandwidth guarantees enterprise

network

Transport Layer: 3-7

Chapter 3: roadmap
▪ Transport-layer services
▪ Multiplexing and demultiplexing
▪ Connectionless transport: UDP
▪ Principles of reliable data transfer
▪ Connection-oriented transport: TCP
▪ Principles of congestion control
▪ TCP congestion control
▪ Evolution of transport-layer
functionality
Transport Layer: 3-8
Multiplexing/demultiplexing
multiplexing as sender: demultiplexing as receiver:
handle data from multiple use header info to deliver
sockets, add transport header received segments to correct
(later used for demultiplexing) socket

application

application P1 P2 application socket

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

Transport Layer: 3-9

 HTTP server
client
application application
HTTP msg
transport
Ht HTTP msg

Hnnetwork
Ht HTTP msg transport
transport
Hn Hnetwork
t HTTP msg
link network
link physical link
physical physical

Hn Ht HTTP msg

Transport Layer: 3-10

 Q: how did transport layer know to deliver message to Firefox
browser process rather then Netflix process or Skype process?

client
application application
HTTP msg
HTTP msg transport
Ht HTTP msg

transport network transport

network link network
link physical link
physical physical

Transport Layer: 3-11

 ?

de-multiplexing
 application

? transport

de-multiplexing
Demultiplexing
multiplexing
 application

transport

multiplexing
Multiplexing
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-18

Connectionless demultiplexing
Recall: when receiving host receives
▪ when creating socket, must UDP segment:
• checks destination port # in
specify host-local port #: segment
DatagramSocket mySocket1 • directs UDP segment to
= new DatagramSocket(12534);
socket with that port #
▪ when creating datagram to
send into UDP socket, must
specify IP/UDP datagrams with same dest.
port #, but different source IP
• destination IP address
addresses and/or source port
• destination port # numbers will be directed to same
socket at receiving host
Transport Layer: 3-19
Connectionless demultiplexing: an example
mySocket =
socket(AF_INET,SOCK_DGRAM)
mySocket.bind(myaddr,6428);
mySocket.bind(myaddr,9157); mySocket.bind(myaddr,5775);

application
application application
P1
P3 P4
transport
transport transport
network
network link network
link physical link
physical physical

B D
source port: 6428 source port: ?
dest port: 9157 dest port: ?

A C
source port: 9157 source port: ?
dest port: 6428 dest port: ?
Connection-oriented demultiplexing
▪ TCP socket identified by ▪ server may support many
4-tuple: simultaneous TCP sockets:
• source IP address • each socket identified by its
• source port number own 4-tuple
• dest IP address • each socket associated with
• dest port number a different connecting client
▪ demux: receiver uses all
four values (4-tuple) to
direct segment to
appropriate socket
Transport Layer: 3-21
Connection-oriented demultiplexing: example
application
application P4 P5 P6 application
P1 P2 P3
transport
transport transport
network
network link network
link physical link
physical server: IP physical
address B

host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
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
Transport Layer: 3-22
Summary
▪ Multiplexing, demultiplexing: based on segment, datagram
header field values
▪ UDP: demultiplexing using destination port number (only)
▪ TCP: demultiplexing using 4-tuple: source and destination IP
addresses, and port numbers
▪ Multiplexing/demultiplexing happen at all layers

Transport Layer: 3-23

Chapter 3: roadmap
▪ Transport-layer services
▪ Multiplexing and demultiplexing
▪ Connectionless transport: UDP
▪ Principles of reliable data transfer
▪ Connection-oriented transport: TCP
▪ Principles of congestion control
▪ TCP congestion control
▪ Evolution of transport-layer
functionality
Transport Layer: 3-24
UDP: User Datagram Protocol
Why is there a UDP?
▪ “no frills,” “bare bones”
Internet transport protocol ▪ no connection
establishment (which can
▪ “best effort” service, UDP add RTT delay)
segments may be: ▪ simple: no connection state
• lost at sender, receiver
• delivered out-of-order to app ▪ small header size
▪ connectionless: ▪ no congestion control
• no handshaking between UDP ▪ UDP can blast away as fast as
desired!
sender, receiver
▪ can function in the face of
• each UDP segment handled congestion
independently of others
Transport Layer: 3-25
UDP: User Datagram Protocol
▪ UDP use:
▪ streaming multimedia apps (loss tolerant, rate sensitive)
▪ DNS
▪ SNMP
▪ HTTP/3
▪ if reliable transfer needed over UDP (e.g., HTTP/3):
▪ add needed reliability at application layer
▪ add congestion control at application layer

Transport Layer: 3-26

UDP: User Datagram Protocol [RFC 768]

Transport Layer: 3-27

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-28

UDP: Transport Layer Actions

SNMP client SNMP server

UDP sender actions:
application ▪ is passed an application- application
SNMP msg
layer message
transport transport
▪ determines UDP segment UDP
UDPhh 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-29

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) (UDP)
▪ extracts application-layer
network
UDP h SNMP(IP)
msg message network (IP)
▪ demultiplexes message up
link link
to application via socket
physical physical

Transport Layer: 3-30

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

Transport Layer: 3-31

UDP checksum
Goal: detect errors (i.e., flipped bits) in transmitted segment
1st number 2nd number sum

Transmitted: 5 6 11

Received: 4 6 11

receiver-computed sender-computed
checksum
= checksum (as received)

Transport Layer: 3-32

Internet checksum
Goal: detect errors (i.e., flipped bits) in transmitted segment
sender: receiver:
▪ treat contents of UDP ▪ compute checksum of received
segment (including UDP header segment
fields and IP addresses) as
sequence of 16-bit integers ▪ check if computed checksum equals
▪ checksum: addition (one’s checksum field value:
complement sum) of segment • not equal - error detected
content • equal - no error detected. But maybe
▪ checksum value put into errors nonetheless? More later ….
UDP checksum field
Transport Layer: 3-33
Internet checksum: an example
example: add two 16-bit integers
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

sum 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

Note: when adding numbers, a carryout from the most significant bit needs to be
added to the result

* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
Transport Layer: 3-34
Internet checksum: weak protection!
example: add two 16-bit integers
0 1
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 Even though
numbers have
sum 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 changed (bit
flips), no change
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 in checksum!

Transport Layer: 3-35

Summary: UDP
▪ “no frills” protocol:
• segments may be lost, delivered out of order
• best effort service: “send and hope for the best”
▪ UDP has its plusses:
• no setup/handshaking needed (no RTT incurred)
• can function when network service is compromised
• helps with reliability (checksum)
▪ build additional functionality on top of UDP in application layer
(e.g., HTTP/3)
Chapter 3: roadmap
▪ Transport-layer services
▪ Multiplexing and demultiplexing
▪ Connectionless transport: UDP
▪ Principles of reliable data transfer
▪ Connection-oriented transport: TCP
▪ Principles of congestion control
▪ TCP congestion control
▪ Evolution of transport-layer
functionality
Transport Layer: 3-37
 Principles of reliable data transfer

sending receiving sending receiving

process process process process
application data data application data data
transport transport
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

Transport Layer: 3-38

Principles of reliable data transfer

sending receiving
process process
application data data
transport

sender-side of receiver-side
Complexity of reliable data reliable data
transfer protocol
of reliable data
transfer protocol
transfer protocol will depend
(strongly) on characteristics of transport
network
unreliable channel (lose, unreliable channel
corrupt, reorder data?)
reliable service implementation

Transport Layer: 3-39

Principles of reliable data transfer

sending receiving
process process
application data data
transport

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-40

rdt1.0: reliable transfer over a reliable channel
▪ underlying channel perfectly reliable
• no bit errors
• no loss of packets

• no segments are lost, corrupted, duplicated or

reordered

Transport Layer: 3-41

rdt2.0: channel with bit errors
▪ underlying channel may flip bits in packet
• checksum to detect bit errors
▪ the question: how to recover from errors?
• acknowledgements (ACKs): receiver explicitly tells sender that pkt
received OK
• negative acknowledgements (NAKs): receiver explicitly tells sender
that pkt had errors
• sender retransmits pkt on receipt of NAK

stop and wait

sender sends one packet, then waits for receiver response
Transport Layer: 3-42
rdt2.0 has a fatal flaw!
what happens if ACK/NAK handling duplicates:
corrupted? ▪ sender retransmits current pkt
▪ sender doesn’t know what if ACK/NAK corrupted
happened at receiver! ▪ sender adds sequence number
▪ can’t just retransmit: possible to each pkt
duplicate ▪ receiver discards (doesn’t
deliver up) duplicate pkt

stop and wait

sender sends one packet, then
waits for receiver response
Transport Layer: 3-43
rdt2.1: discussion
sender: receiver:
▪ seq # added to pkt ▪ must check if received packet
▪ two seq. #s (0,1) will suffice. is duplicate
Why? • state indicates whether 0 or 1 is
expected pkt seq #
▪ must check if received ACK/NAK
corrupted ▪ note: receiver can not know if
its last ACK/NAK received OK
▪ twice as many states at sender
• state must “remember” whether
“expected” pkt should have seq #
of 0 or 1

Transport Layer: 3-44

rdt2.2: a NAK-free protocol
▪ same functionality as rdt2.1, using ACKs only
▪ instead of NAK, 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 NAK:
retransmit current pkt

As we will see, TCP uses this approach to be NAK-free

Transport Layer: 3-45

 rdt3.0: channels with errors and loss
New channel assumption: underlying channel can also lose
packets (data, ACKs)
• checksum, sequence #s, ACKs, retransmissions will be of help …
but not quite enough
Approach: sender waits “reasonable” amount of time for ACK
▪ retransmits if no ACK received in this time
▪ if pkt (or ACK) just delayed (not lost):
• retransmission will be duplicate, but seq #s already handles this!
• receiver must specify seq # of packet being ACKed
▪ use countdown timer to interrupt after “reasonable” amount
of time timeout
Transport Layer: 3-46
rdt3.0 in action
sender receiver sender receiver
send pkt0 pkt0 send pkt0 pkt0
rcv pkt0 rcv pkt0
ack0 send ack0 ack0 send ack0
rcv ack0 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-47
rdt3.0 in action
sender receiver
sender receiver send pkt0
pkt0
rcv pkt0
send pkt0 pkt0 send ack0
ack0
rcv pkt0 rcv ack0
ack0 send ack0 send pkt1 pkt1
rcv ack0 rcv pkt1
send pkt1 pkt1 send ack1
rcv pkt1 ack1
ack1 send ack1
X timeout
loss resend pkt1
timeout
pkt1 rcv pkt1
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 pkt1

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

Transport Layer: 3-48
 Stop and wait – Summary
▪ Sends a data frame and then waits for an acknowledgment (ACK) from the receiver
indicating that the receiver successfully received the data frame. After receiving the ACK
from the receiver, the sender delivers the next data frame.
▪ Sender window size (Ws) = 1, Receiver window size (Wr) = 1
▪ Sequence Numbers 0 and 1
▪ Uses independent acknowledgement and Discards out of order packets
▪ Packet Loss ? Retransmit packet after time out
▪ Acknowledgement loss ? Resends packet after time out
▪ ADV: Simple Implementation, Error Detection, Reliable, Flow Control
▪ DISADV: Low Efficiency, High Latency, Limited Bandwidth Utilization, No Error Recovery

Transport Layer: 3-49

Review
▪ In Stop and wait protocol every 4th packet is lost and we need to
send total 10 packets so how many transmission it took to send all
the packets?

▪ Which ARQ protocol for data transmission

is being implemented here? Demonstrate its
Features and working.
Transport Layer: 3-50
rdt3.0: 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-51

Go-Back-N: sender
▪ sender: “window” of up to N, consecutive transmitted but unACKed pkts
• k-bit seq # in pkt header

▪ cumulative ACK: ACK(n): ACKs all packets up to, including seq # n

• on receiving ACK(n): move window forward to begin at n+1
▪ timer for oldest in-flight packet
▪ timeout(n): retransmit packet n and all higher seq # packets in window
Transport Layer: 3-52
Go-Back-N in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, discard,
012345678 rcv ack0, send pkt4 (re)send ack1
012345678 rcv ack1, send pkt5 receive pkt4, discard,
(re)send ack1
ignore duplicate ACK receive pkt5, discard,
(re)send ack1
pkt 2 timeout
012345678 send pkt2
012345678 send pkt3
012345678 send pkt4 rcv pkt2, deliver, send ack2
012345678 send pkt5 rcv pkt3, deliver, send ack3
rcv pkt4, deliver, send ack4
rcv pkt5, deliver, send ack5

Transport Layer: 3-53

 Go Back N – Summary
Go-Back-N ARQ allows sending more than one frame before getting the first frame’s acknowledgment. There is a limit to
the amount of frames that can be sent, and they are numbered consecutively. All frames beginning with that frame are
retransmitted if the acknowledgment is not received in a timely manner.
▪ Sender window size Ws = N
▪ Receiver window size Wr = 1
▪ Sequence number ≥ N + 1
▪ Can use both cumulative or independent acknowledgement depends on acknowledge timer
▪ Discards out of order packets
▪ Packet Loss ? Track back N size from the last packet within the window limit to the lost packet and retransmit them
▪ Acknowledgement loss ? If not received before timeout the entire window N size is resend
▪ Efficiency = N/(1+2a) where a = Tp / Tt
▪ ADV: Simple to implement and effective for reliable communication, Better performance than stop-and-wait protocols
for error-free or low-error networks.
▪ DISADV: Inefficient if errors are frequent, Bandwidth can be wasted due to redundant retransmissions

Transport Layer: 3-54

▪ In Go-Back-N ARQ protocol, ▪ In Go-Back-N ARQ, why does
assume the sender window size the sender retransmit all
is N=4 and the receiver window packets from the lost packet
size is 1. If every 5th packet is onwards instead of just the lost
lost and we need to send a total packet?
of 7 packets, how many
transmissions are required to
send all the packets ▪ If the sender's window size is
successfully? increased, how does it impact
the performance of Go-Back-N
ARQ? What are the advantages
and disadvantages?

Transport Layer: 3-55

Selective repeat: the approach
▪pipelining: multiple packets in flight
▪receiver individually ACKs all correctly received packets
• buffers packets, as needed, for in-order delivery to upper layer
▪sender:
• maintains (conceptually) a timer for each unACKed pkt
• timeout: retransmits single unACKed packet associated with timeout
• maintains (conceptually) “window” over N consecutive seq #s
• limits pipelined, “in flight” packets to be within this window

Transport Layer: 3-56

Selective repeat: sender, receiver windows

Transport Layer: 3-57

Selective Repeat in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, buffer,
012345678 rcv ack0, send pkt4 send ack3
012345678 rcv ack1, send pkt5
receive pkt4, buffer,
record ack3 arrived send ack4
receive pkt5, buffer,
pkt 2 timeout send ack5
012345678 send pkt2
012345678 (but not 3,4,5)
012345678 rcv pkt2; deliver pkt2,
012345678 pkt3, pkt4, pkt5; send ack2

Q: what happens when ack2 arrives?

Transport Layer: 3-58

 sender window receiver window
Selective repeat: (after receipt)

pkt0
(after receipt)

a dilemma!
0123012
0123012 pkt1 0123012
0123012 pkt2 0123012
0123012
example: 0123012 pkt3
X
▪ seq #s: 0, 1, 2, 3 (base 4 counting)
0123012
pkt0 will accept packet
with seq number 0
▪ window size=3 (a) no problem

0123012 pkt0
0123012 pkt1 0123012
0123012 pkt2 X 0123012
X 0123012
X
timeout
retransmit pkt0
0123012 pkt0
will accept packet
with seq number 0
(b) oops!
Transport Layer: 3-59
Selective Repeat – Summary
Selective repeat protocol allows the receiver to accept and buffer the frames following a
damaged or lost one. Selective Repeat attempts to retransmit only those packets that are
actually lost.
▪ Sender window size Ws = N
▪ Receiver window size Wr = N
▪ Sequence Number ≥ N + N
▪ Uses only independent acknowledgement
▪ Can Accept out of order packets
▪ Packet Loss ? Resend only the lost packet after timeout
▪ Acknowledgement loss ? Resend if not receive before timeout
▪ ADV: Provides efficient transmission of packets, Only lost packets are retransmitted,
reducing network congestion
▪ DISADV: Requires more memory and processing power

Transport Layer: 3-60

Assume a sender sends 6 packets: packets 0, 1, 2, 3, 4, and 5. The
sender receives an ACK with ackNo = 3. What is the interpretation if
the system is using GBN or SR?

Suppose the sender in Selective Repeat ARQ has a window size of 4 and the receiver also has a window
size of 4. The sender transmits packets 1, 2, 3, and 4, but packet 2 is lost. What happens next? Describe
the behavior of both sender and receiver.

In Selective Repeat ARQ, if an ACK is lost due to network issues, what happens? How does the
sender ensure reliable transmission?

Transport Layer: 3-61

Go-Back-N Protocol Selective Repeat Protocol
In Go-Back-N Protocol, if the sent frame are find suspected
In selective Repeat protocol, only those frames are re-
then all the frames are re-transmitted from the lost packet to
transmitted which are found suspected.
the last packet transmitted.

Sender window size of Go-Back-N Protocol is N. Sender window size of selective Repeat protocol is also N.

Receiver window size of Go-Back-N Protocol is 1. Receiver window size of selective Repeat protocol is N.
Go-Back-N Protocol is less complex. Selective Repeat protocol is more complex.
In Go-Back-N Protocol, neither sender nor at receiver need In selective Repeat protocol, receiver side needs sorting to
sorting. sort the frames.
In Go-Back-N Protocol, type of Acknowledgement is In selective Repeat protocol, type of Acknowledgement is
cumulative. individual.
In Go-Back-N Protocol, Out-of-Order packets are NOT
In selective Repeat protocol, Out-of-Order packets are
Accepted (discarded) and the entire window is re-
Accepted.
transmitted.
In selective Repeat protocol, if Receives a corrupt packet, it
In Go-Back-N Protocol, if Receives a corrupt packet, then
immediately sends a negative acknowledgement and hence
also, the entire window is re-transmitted.
only the selective packet is retransmitted.
Efficiency of Go-Back-N Protocol is Efficiency of selective Repeat protocol is also
N/(1+2*a) N/(1+2*a) Transport Layer: 3-62
 Stop-and-Wait Protocol Sliding Window Protocol
In sliding window protocol, sender sends more than one frame
In Stop-and-Wait Protocol, sender sends one frame and wait
to the receiver side and re-transmits the frame(s) which is/are
for acknowledgment from receiver side.
damaged or suspected.
Efficiency of Stop-and-Wait Protocol is worse. Efficiency of sliding window protocol is better.
Sender window size of Stop-and-Wait Protocol is 1. Sender window size of sliding window protocol is N.
Receiver window size of Stop-and-Wait Protocol is 1. Receiver window size of sliding window protocol may be 1 or N.
In sliding window protocol, sorting may be or may not be
In Stop-and-Wait Protocol, sorting is not necessary.
necessary.
Efficiency of Stop-and-Wait Protocol is 1/(1+2*a) Efficiency of sliding window protocol is N/(1+2*a)
Stop-and-Wait Protocol is mostly used in low speed and error Sliding window protocol is mostly used in high speed and error-
free network. prone network.
In Stop-and-Wait Protocol, the sender cannot send any new In sliding window protocol, the sender can continue to send
frames until it receives an acknowledgment for the previous new frames even if some of the earlier frames have not yet
frame. been acknowledged.
Stop-and-Wait Protocol has a lower throughput as it has a lot of Sliding window protocol has a higher throughput as it allows for
idle time while waiting for the acknowledgment. continuous transmission of frames.

Transport Layer: 3-63

The protocols discussed are all unidirectional: data packets flow in only one
direction and acknowledgments travel in the other direction. In real life, data
packets are normally flowing in both directions: from client to server and
from server to client. This means that acknowledgments also need to flow in
both directions. A technique called piggybacking is used to improve the
efficiency of the bidirectional protocols.

Design of piggybacking in Go-Back-N

Transport Layer: 3-64