Computer Networks

(CCS-503)
Transport Layer
Assoc. Prof. Dr. Mennan Selimi
Max van der Stoel Institute, South East European University,
https://mvdsi.seeu.edu.mk/mselimi/
South East European University
30th of October 2024
 Syllabus (2024/25 - 15 weeks)
Week 1 Week 2 Week 3 Week 4 Week 5
25/09 02/10 09/10 16/10 23/10
Administrative
Network Core Web,HTTP, FTP Web,HTTP, FTP
details Public Holiday
Protocol Layers SMTP, DNS SMTP, DNS
What is Internet? NO CLASSES
Service Model P2P P2P
Network Edge

Week 6 Week 7 Week 8 Week 9 Week 10

30/10 06/11 06/11
13/11 20/11 27/11
Internet Protocol Internet Protocol Internet Protocol
TCP, UDP Midterm Week
Routing Routing Routing
TCP Congestion NO CLASSES
algorithms
NO CLASSES algorithms algorithms
OSPF, BGP OSPF, BGP OSPF, BGP

Week 11 Week 12 Week 13 Week 14 Week 15

04/12 11/12 18/12 25/12 01/01
Internet Protocol Cloud Networking in
WiFi: 802.11
Routing Error detection Computing Data Centres
Cellular Network
algorithms LAN, MPLS Edge Computing Google Cloud
3G, 4G, Mobile IP
OSPF, BGP Platform
Homework 2
Due: October 30 (Wednesday), 23:59
Submission will be closed after 30th of October
2% penalty for late submission till 31/12/2024

Midterm 1 consultations
Friday (01/11) from 09.30-10.30 and 10.30-11.30 (304.08)
Transport Layer COMPSCI 453 Computer Networks
Professor Jim Kurose
College of Information and Computer Sciences
▪ Introduction: transport-layer services University of Massachusetts

▪ Multiplexing and demultiplexing

▪ Connectionless transport: UDP
Class textbook:
▪ Principles of reliable data transfer Computer Networking: A Top-
Down Approach (8th ed.)
▪ Connection-oriented transport: TCP J.F. Kurose, K.W. Ross
Pearson, 2020

▪ Principles of congestion control http://gaia.cs.umass.edu/kurose_ross

▪ TCP congestion control

▪ Evolution of transport-layer functionality
Layered Internet protocol stack
▪ application: supporting network applications
• HTTP, IMAP, SMTP, DNS application
application
▪ transport: process-process data transfer
• TCP, UDP transport
transport
▪ network: routing of datagrams from source to network
destination
• IP, routing protocols link
▪ link: data transfer between neighboring
network elements physical
• Ethernet, 802.11 (WiFi), PPP
▪ physical: bits “on the wire”
Transport layer: overview
Our goal:
▪ understand principles ▪ learn about Internet transport
behind transport layer layer protocols:
services: • UDP: connectionless transport
• multiplexing, demultiplexing • TCP: connection-oriented
• reliable data transfer reliable transport
• flow control
• TCP congestion control
• congestion control
Transport services and protocols
application
transport

▪ provide logical communication

network
mobile network
data link
physical

between application processes national or global ISP

l og
running on different hosts

ica
l en
▪ transport protocols actions in end

d -e
systems:

nd
local or

tra
• sender: breaks application messages into regional ISP

n sp
segments, passes to network layer

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

▪ two transport protocols available to

data link
physical

Internet applications enterprise

network
• TCP, UDP
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 vs. network layer services and protocols
household analogy:
▪ network layer: logical
communication between 12 kids in Ann’s house sending
letters to 12 kids in Bill’s house:
hosts
▪ hosts = houses
▪ transport layer: logical ▪ processes = kids
communication between ▪ app messages = letters in
envelopes
processes
▪ transport protocol = Ann and Bill
• relies on, enhances, network who demux to in-house siblings
layer services ▪ network-layer protocol = postal
service
Transport Layer Actions

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

link
▪ passes segment to IP link

physical physical
Transport Layer Actions

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

physical physical
Th app. msg
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

l og
• congestion control

ica
l en
• flow control

d -e
• connection setup

nd
local or

tra
▪ UDP: User Datagram Protocol regional ISP

n sp
ort
• unreliable, unordered delivery home network content
provider
• no-frills extension of “best-effort” IP network datacenter
applicationnetwork
transport

▪ services not available: network

data link
physical
• delay guarantees
enterprise
• bandwidth guarantees network
Transport Layer COMPSCI 453 Computer Networks
Professor Jim Kurose
College of Information and Computer Sciences
▪ Transport-layer services University of Massachusetts

▪ Multiplexing and demultiplexing

▪ Connectionless transport: UDP
Class textbook:
▪ Principles of reliable data transfer Computer Networking: A Top-
Down Approach (8th ed.)
▪ Connection-oriented transport: TCP J.F. Kurose, K.W. Ross
Pearson, 2020

▪ Principles of congestion control

http://gaia.cs.umass.edu/kurose_ross

▪ TCP congestion control

▪ Evolution of transport-layer functionality
multiplexing
 application

transport

multiplexing
 ?

de-multiplexing
 application

? transport

de-multiplexing
 HTTP server
client
application application

transport

transport network transport

network link network
link physical link
physical physical
 HTTP server
client
application application

transport

transport network transport

network link network
link physical link
physical physical
 HTTP server
client1 client2
application P-client1 P-client2 application

transport

transport network transport

network link network
link physical link
physical physical
Multiplexing
Demultiplexing
Multiplexing/demultiplexing
multiplexing at sender: demultiplexing at 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
 HTTP server
client
application application
HTTP msg

transport
Ht HTTP msg

Hnnetwork
Ht HTTP msg
transport transport
network link network
link physical link
physical physical
 HTTP server
client
application application

transport

transport network transport

network link network
link physical link
physical physical

Hn Ht HTTP msg
 HTTP server
client1 client2
application P-client1 P-client2 application

transport

transport network transport

network link network
link physical link
physical physical
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
(payload)
▪ host uses IP addresses & port
numbers to direct segment to
appropriate socket TCP/UDP segment format
Connectionless demultiplexing
Recall: when receiving host receives
▪ when creating socket, must specify UDP segment:
host-local port #: • checks destination port # in
DatagramSocket mySocket1 = new segment
DatagramSocket(12534);
• directs UDP segment to socket
with that port #
▪ when creating datagram to
send into UDP socket, must IP/UDP datagrams with same dest.
specify 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
 Connectionless demultiplexing: an example
DatagramSocket
serverSocket = new
DatagramSocket
DatagramSocket mySocket2 = (6428); DatagramSocket mySocket1 =
new DatagramSocket new DatagramSocket (5775);
(9157); application
application application
P1
P3 P4
transport
transport transport
network
network link network
link physical link
physical physical

source port: 6428 source port: ?

dest port: 9157 dest port: ?

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 a
• dest port number different connecting client
▪ demux: receiver uses all
four values (4-tuple) to
direct segment to
appropriate socket
Connection-oriented demultiplexing: example
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: IP address A source IP,port: B,80 host: IP address C

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
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 COMPSCI 453 Computer Networks
Professor Jim Kurose
College of Information and Computer Sciences
▪ Transport-layer services University of Massachusetts

▪ Multiplexing and demultiplexing

▪ Connectionless transport: UDP
Class textbook:
▪ Principles of reliable data transfer Computer Networking: A Top-
Down Approach (8th ed.)
▪ Connection-oriented transport: TCP J.F. Kurose, K.W. Ross
Pearson, 2020

▪ Principles of congestion control

http://gaia.cs.umass.edu/kurose_ross

▪ TCP congestion control

▪ Evolution of transport-layer functionality
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
sender, receiver desired!
• each UDP segment handled ▪ can function in the face of
congestion
independently of others
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
▪ acc congestion control at application layer
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
checksum
= sender-computed
checksum (as received)
UDP checksum
Goal: detect errors (i.e., flipped bits) in transmitted segment

sender: receiver:
▪ treat contents of UDP segment ▪ compute checksum of received
(including UDP header fields and IP
addresses) as sequence of 16-bit segment
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 UDP errors nonetheless? More later ….
checksum field
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/
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)
Transport Layer COMPSCI 453 Computer Networks
Professor Jim Kurose
College of Information and Computer Sciences
▪ Transport-layer services University of Massachusetts

▪ Multiplexing and demultiplexing

▪ Connectionless transport: UDP
▪ Principles of reliable data transfer Class textbook:
Computer Networking: A Top-
Connection-oriented transport: TCP Down Approach (8th ed.)
J.F. Kurose, K.W. Ross

▪ Principles of congestion control

Pearson, 2020
http://gaia.cs.umass.edu/kurose_ross

▪ TCP congestion control

▪ Evolution of transport-layer functionality
 Principles of reliable data transfer

sending receiving
process process
application data data
transport
reliable channel

reliable service abstraction

 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

Principles of reliable data transfer

sending receiving
process process
application data data
transport

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

sending receiving
process process
application data data
transport

sender-side of receiver-side
Sender, receiver do not know reliable data of reliable data
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
 Reliable data transfer protocol (rdt): interfaces
rdt_send(): called from above,
deliver_data(): called by rdt
(e.g., by app.). Passed data to
to deliver data to upper layer
deliver to receiver upper layer
sending receiving
process process
rdt_send() data data
deliver_data()

sender-side data receiver-side

implementation of implementation of
rdt reliable data packet rdt reliable data
transfer protocol transfer protocol
udt_send() Header data Header data rdt_rcv()

unreliable channel
udt_send(): called by rdt rdt_rcv(): called when packet
to transfer packet over Bi-directional communication over arrives on receiver side of
unreliable channel to receiver unreliable channel channel
Reliable data transfer: getting started
We will:
▪ incrementally develop sender, receiver sides of reliable data transfer
protocol (rdt)
▪ consider only unidirectional data transfer
• but control info will flow on both directions!
▪ use finite state machines (FSM) to specify sender, receiver
event causing state transition
actions taken on state transition
state: when in this “state”
next state uniquely state state
determined by next 1 event
2
event actions
 Turn switch ON
power to filament

OFF ON

Turn switch OFF

no power to filament
rdt1.0: reliable transfer over a reliable channel
▪ underlying channel perfectly reliable
• 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)

sender call from
above
packet = make_pkt(data) receiver call from extract (packet,data)
udt_send(packet) below deliver_data(data)
rdt2.0: channel with bit errors
▪ underlying channel may flip bits in packet
• checksum (e.g., Internet checksum) to detect bit errors
▪ the question: how to recover from errors?

How do humans recover from “errors” during conversation?

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
rdt2.0: FSM specifications
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Wait for Wait for isNAK(rcvpkt)
sender call from ACK or udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt)
above NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Λ Wait for
call from receiver
below

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt2.0: FSM specification
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Wait for Wait for isNAK(rcvpkt)
sender call from ACK or udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt)
above NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Λ Wait for
call from receiver
below

Note: “state” of receiver (did the receiver get my

message correctly?) isn’t known to sender unless rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
extract(rcvpkt,data)
somehow communicated from receiver to sender deliver_data(data)
▪ that’s why we need a protocol! udt_send(ACK)
rdt2.0: operation with no errors
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Wait for Wait for isNAK(rcvpkt)
sender call from ACK or udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt)
above NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
Λ
call from receiver
below

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt2.0: corrupted packet scenario
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Wait for Wait for isNAK(rcvpkt)
sender call from ACK or udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt)
above NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
Λ
call from receiver
below

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt2.0 has a fatal flaw!
what happens if ACK/NAK handling duplicates:
corrupted? ▪ sender retransmits current pkt if
▪ sender doesn’t know what ACK/NAK corrupted
happened at receiver! ▪ sender adds sequence number to
▪ can’t just retransmit: possible each pkt
duplicate ▪ receiver discards (doesn’t deliver
up) duplicate pkt
stop and wait
sender sends one packet, then
waits for receiver response
rdt2.1: sender, handling garbled ACK/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
above NAK 0 udt_send(sndpkt)
rdt_rcv(rcvpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) &&
&& notcorrupt(rcvpkt)
isACK(rcvpkt)
&& isACK(rcvpkt)
Λ
Λ
Wait for Wait for
ACK or call 1 from
rdt_rcv(rcvpkt) NAK 1 above
&& (corrupt(rcvpkt) ||
isNAK(rcvpkt) ) rdt_send(data)

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

udt_send(sndpkt)
rdt2.1: receiver, handling garbled ACK/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.1: discussion
sender: receiver:
▪ seq # added to pkt ▪ must check if received packet
▪ two seq. #s (0,1) will suffice. Why? is duplicate
▪ must check if received ACK/NAK • state indicates whether 0 or 1 is
expected pkt seq #
corrupted
▪ twice as many states ▪ note: receiver can not know if
its last ACK/NAK received OK
• state must “remember” whether
“expected” pkt should have seq # of 0 at sender
or 1
rdt3.0: channels with errors and loss
New channel assumption: Approach: sender waits
underlying channel can also “reasonable” amount of time
lose packets (data, ACKs) for ACK
• checksum, seq. #, ACKs, ▪ retransmits if no ACK received in
retransmissions will be of help this time
… but not enough
▪ if pkt (or ACK) just delayed (not
lost):
• retransmission will be duplicate, but
How do humans handle seq. #s already handles this
lost sender-to-receiver • receiver must specify seq # of pkt
words in conversation? being ACKed
▪ requires countdown timer
rdt3.0: channels with errors and loss
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
rdt3.0 sender
rdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) start_timer Λ
Λ Wait for Wait
for timeout
call 0from
ACK0 udt_send(sndpkt)
above
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
Wait Wait for
timeout for call 1 from
udt_send(sndpkt) ACK1 above
start_timer rdt_rcv(rcvpkt)
Λ
rdt_send(data)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt)
start_timer
Λ
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
pkt1 send pkt1 pkt1
send pkt1
rcv pkt1 X
loss
ack1 send ack1
rcv ack1
send pkt0 pkt0
rcv pkt0 timeout pkt1
ack0 send ack0 resend pkt1
rcv pkt1
ack1 send ack1
rcv ack1
send pkt0 pkt0
(a) no loss rcv pkt0
ack0 send ack0

(b) packet loss

rdt3.0 in action
sender receiver
sender receiver send pkt0 pkt0
rcv pkt0
send pkt0 pkt0 ack0 send 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 pkt1
resend pkt1 rcv pkt1
timeout (detect duplicate)
resend pkt1 pkt1
rcv pkt1 rcv ack1 pkt0
send pkt0 send ack1
(detect duplicate) ack1
ack1 send ack1 rcv ack1 ack0
rcv pkt0
rcv ack1 send pkt0 send ack0
send pkt0 pkt0 pkt0
rcv pkt0
rcv pkt0 ack0 (detect duplicate)
ack0 send ack0 send ack0
(d) premature timeout/ delayed ACK
(c) ACK loss
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

Q: How do humans handle lost sender-to-

receiver words in conversation?
Midterm Exercises

65
66
Consider the case when a server is distributing the file F=6x10power6 bits to 5 peers. The upload
speed rate of the server equals the link transmission rate (R = 3 Mbps). The download rate of the peers
is d1 = d2 = 2 Mbps and d3 = d4 =d5= 1 Mbps and upload speed rate is Ui= 1 Mbps respectively.

Calculate the maximum distribution time for Client-Server and P2P architecture for this problem.

67
 1. Assuming zero transmission time for the HTML object, how much time (in msec) elapses from when the client clicks on the link until the client receives the object?

2. Now suppose the HTML object references 5 very small objects on the same server. Neglecting transmission times, how much time (in msec) elapses from when the client
clicks on the link until the base object and all 5 additional objects are received from web server at the client, assuming non-persistent HTTP and no parallel TCP
connections?

68
69
70
71
 Mennan Selimi
Thank you ! [email protected]
https://www.mvdsi.seeu.edu.mk