Advance Computer

Networks

Unit-2
Transport Layer

Dr. Vijeta Khare

Outline
▪ Introduction and Transport Layer Services
▪ Multiplexing and Demultiplexing
▪ Connection less transport (UDP)
▪ Principles of Reliable Data Transfer
▪ Connection oriented transport (TCP)
▪ Congestion control
Transport Layer Services and Protocols
▪ It provides logical communication application
transport
between application processes network
data link
physical
running on different hosts.
▪ A transport protocols run in end

lo
gi
ca
le
systems.

nd
-e
▪ Sender side: It breaks application

nd
tra
ns
messages into segments, then

po
rt
passes to network layer.
application
▪ Receiver side: It reassembles transport
network
data link
segments into messages, then physical

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 / Demultiplexing
Multiplexing at sender:
To handle data from multiple Demultiplexing at receiver:
sockets, add transport header Use header information to
(later used for demultiplexing) deliver received segments
to correct socket
application

application P1 P2 application socket

P3 transport P4
process
transport network transport
network link network
link physical link
physical physical
How demulptiplexing works?
▪ A host PC receives IP
datagrams. 32 bits
▪ Each datagram has source IP source port # dest port #
address and destination IP
address. other header fields
▪ Each datagram carries one
transport-layer segment.
▪ Each segment has source and Application data
(message)
destination port number.
▪ A host PC uses IP addresses &
port numbers to direct
segment to appropriate TCP/UDP segment format
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 mySocket2 DatagramSocket serverSocket = DatagramSocket

= new DatagramSocket new DatagramSocket mySocket1 = new
(9157); (6428); DatagramSocket (5775);
application
application application
P1
P3 P4
transport
transport transport
network
network link network
link physical link
physical 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 sockets for 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:
IP address C
host: source IP,port: B,80
dest IP,port: A,9157 source IP,port: C,5775
IP address A 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
PRINCIPLES OF RELIABLE DATA TRANSFER
Principles of reliable data transfer

▪ Characteristics of unreliable channel will determine complexity of

reliable data transfer protocol (rdt)
Reliable Data Transfer(rdt)
rdt_send(): called from above layer, deliver_data(): called by rdt to
(e.g., by application layer). deliver data to upper layer
Passed data to receiver

sender receiver
side side

udt_send(): called by rdt, rdt_rcv(): called when packet arrives on

to transfer packet over receiver side of channel
unreliable channel to receiver
Reliable Data Transfer – Cont…
▪ Consider only unidirectional data transfer.
✔ A control information will flow on both directions.
▪ Use finite state machines (FSM) to specify sender and receiver.
▪ When in this “state” next state uniquely determined by next
event.
▪ Arrow indicates the transition of protocol from one state to
another.
event causing state transition
actions taken on state transition

state state
1 event
2
actions
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 – STOP & WAIT PROTOCOL
rdt 2.0 – channel with bit errors
▪ Underlying channel may flip bits in packet.
✔ checksum to detect bit errors.
▪ To recover from errors:
✔ acknowledgements (ACKs): receiver explicitly 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 receiver to sender
✔ Retransmission: Error in received packet, retransmitted by the sender
▪ It is known as stop-and-wait protocol.
rdt 2.0 – with no error
rdt_send(data)
snkpkt = make_pkt(data, checksum) receiver
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above 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 – with error
rdt_send(data)
snkpkt = make_pkt(data, checksum) receiver
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above 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 – FSM Specification
rdt_send(data)
sndpkt = make_pkt(data, checksum) receiver
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above 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.1 - HANDLED ACKS/NAKS
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 - 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
ACK or
isNAK(rcvpkt) )
call 0 from
NAK 0 udt_send(sndpkt)
above
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(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)
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)
RDT 2.2 & RDT 3.0
rdt 2.2
▪ Use same functionality as rdt2.1, using ACKs only
▪ Instead of NAK, receiver sends ACK for last packet received OK
▪ Receiver must explicitly include sequence # of packet being ACKed
▪ Duplicate ACK at sender results in same action as NAK: retransmit
current packet.
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 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.
Rdt 3.0: Alternating-bit protocol
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
ack1 send ack1 loss
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

Rdt 3.0 – Cont…
sender receiver
sender receiver send pkt0 pkt0
send pkt0 pkt0 rcv pkt0
ack0 send ack0
rcv pkt0
send ack0 rcv ack0
ack0 send pkt1 pkt1
rcv ack0 rcv pkt1
send pkt1 pkt1
rcv pkt1 send ack1
ack1 ack1
send ack1
X
loss timeout
resend pkt1 pkt1
rcv pkt1
timeout
resend pkt1 pkt1 rcv ack1 pkt0 (detect duplicate)
rcv pkt1 send pkt0 send ack1
(detect duplicate) ack1
ack1 send ack1 rcv ack1 rcv pkt0
rcv ack1 ack0 send ack0
pkt0 send pkt0 pkt0
send pkt0 rcv pkt0
rcv pkt0 ack0 (detect duplicate)
ack0 send ack0 send ack0

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

UDP SEGMENT STRUCTURE
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 Segment - Header
length (in bytes)
32 bits UDP segment - including header
source port # dest port #
length checksum
UDP
▪ no connection
application establishment (which can
data add delay)
(payload) ▪ simple: no connection
state at sender, receiver
▪ small header size
UDP segment format ▪ no congestion control:
UDP can blast away as fast
as desired
Applications of UDP:
▪ Used for simple request-response communication when the size of data
is less and hence there is lesser concern about flow and error control
▪ UDP is widely used in online gaming, where low latency and high-speed
communication is essential for a good gaming experience. Game servers
often send small, frequent packets of data to clients, and UDP is well
suited for this type of communication as it is fast and lightweight.
▪ VoIP (Voice over Internet Protocol) services, such as Skype and
WhatsApp, use UDP for real-time voice communication.
▪ DNS (Domain Name System) also uses UDP for its query/response
messages. DNS queries are typically small and require a quick response
time, making UDP a suitable protocol for this application.
▪ DHCP (Dynamic Host Configuration Protocol) uses UDP to dynamically
assign IP addresses to devices on a network.
▪ Following implementations uses UDP as a transport layer
protocol:
✔ NTP (Network Time Protocol)
✔ DNS (Domain Name Service)
✔ BOOTP, DHCP.
✔ NNP (Network News Protocol)
✔ Quote of the day protocol
✔ TFTP, RTSP, RIP.
▪ The application layer can do some of the tasks through UDP-
✔ Trace Route
✔ Record Route
✔ Timestamp
Advantages of UDP:

▪ 1. Speed: UDP is faster than TCP because it does not have the overhead of establishing a connection and ensuring
reliable data delivery.
▪ 2. Lower latency: Since there is no connection establishment, there is lower latency and faster response time.
▪ 3. Simplicity: UDP has a simpler protocol design than TCP, making it easier to implement and manage.
▪ 4. Broadcast support: UDP supports broadcasting to multiple recipients, making it useful for applications such as
video streaming and online gaming.
▪ 5. Smaller packet size: UDP uses smaller packet sizes than TCP, which can reduce network congestion and improve
overall network performance.

Disadvantages of UDP:

▪ 1. No reliability
▪ 2. No congestion control
▪ 3. No flow control
▪ 4. Vulnerable to attacks
▪ 5. Limited use cases: UDP is not suitable for applications that require reliable data delivery, such as email or file
transfers, and is better suited for applications that can tolerate some data loss, such as video streaming or online
gaming.
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 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
✔ YES - no error detected
 Checksum - Example
▪ Add two 16-bit integers word

Sender Receiver
1 1110011001100110 1 1110011001100110
1 1101010101010101 1 1101010101010101
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1011101110111011
+ +
sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 1 1011101110111100
sum
checksum 0100010001000011 1 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
TCP SEGMENT STRUCTURE
TCP Segment Structure
32 bits
URG: urgent data counting
(generally not used) source port # dest port #
by bytes
sequence number of data
ACK: ACK #
valid acknowledgement number (not segments)
head not
PSH: push data now len used
UAP R S F receive window
(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)

Transport Layer 3-40

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.
Congestion Policy in TCP
▪ Slow Start Phase: Starts slow increment is exponential to the
threshold.
▪ Congestion Avoidance Phase: After reaching the threshold
increment is by 1.
▪ Congestion Detection Phase: The sender goes back to the Slow
start phase or the Congestion avoidance phase.
Slow Start Phase
▪ Exponential increment: In this phase after every
RTT the congestion window size increments
exponentially.
▪ Example:- If the initial congestion window size is 1
segment, and the first segment is successfully
acknowledged, the congestion window size
becomes 2 segments. If the next transmission is
also acknowledged, the congestion window size
doubles to 4 segments. This exponential growth
continues as long as all segments are successfully
acknowledged.
▪ Initially cwnd = 1
▪ After 1 RTT, cwnd = 2^(1) = 2
▪ 2 RTT, cwnd = 2^(2) = 4
▪ 3 RTT, cwnd = 2^(3) = 8
▪ This phase continues until the congestion window size reaches the
slow start threshold.

▪ Threshold
▪ = Maximum number of TCP segments that receiver window can
accommodate / 2
▪ = (Receiver window size / Maximum Segment Size) / 2
Congestion Avoidance Phase
▪ Additive increment: This phase starts after the threshold value also
denoted as ssthresh. The size of cwnd(congestion window) increases
additive. After each RTT cwnd = cwnd + 1.

▪ Example:- if the congestion window size is 20 segments and all 20

segments are successfully acknowledged within an RTT, the congestion
window size would be increased to 21 segments in the next RTT. If all 21
segments are again successfully acknowledged, the congestion window
size would be increased to 22 segments, and so on.

▪ Initially cwnd = i
▪ After 1 RTT, cwnd = i+1
▪ 2 RTT, cwnd = i+2
▪ 3 RTT, cwnd = i+3
Congestion Detection Phase
▪ Multiplicative decrement: If congestion occurs, the congestion window size is decreased.
▪ The only way a sender can guess that congestion has happened is the need to retransmit a
segment.
▪ Retransmission is needed to recover a missing packet that is assumed to have been dropped by
a router due to congestion.
▪ Retransmission can occur in one of two cases: when the RTO timer times out or when three
duplicate ACKs are received.

▪ Case 1: Retransmission due to Timeout – In this case, the congestion possibility is high.
▪ (a) ssthresh is reduced to half of the current window size.
▪ (b) set cwnd = 1
▪ (c) start with the slow start phase again.

▪ Case 2: Retransmission due to 3 Acknowledgement Duplicates – The congestion possibility is

less.
▪ (a) ssthresh value reduces to half of the current window size.
▪ (b) set cwnd= ssthresh
▪ (c) start with congestion avoidance phase
Thank You