Professional Documents
Culture Documents
Unit-3 Transport
Layer
lo
A transport protocols run in end
gi
ca
l
systems.
en
d-
en
Sender side: It breaks application
d
tra
ns
messages into segments, then
orp
t
passes to network layer.
application
Receiver side: It reassembles transport
network
data link
segments into messages, then physical
East Side
Hosts(End Systems) = Houses
Processes = Cousins
Multiplexing – Demultiplexing –
• Gathering data from • Delivering received
multiple application segments at receiver side to
processes of sender, the correct app layer
enveloping that data with processes is called as
header and sending them as demultiplexing.
a whole to the intended
receiver is called as
multiplexing.
Multiplexing and Demultiplexing in Transport Layer
How Multiplexing and Demultiplexing is done –
For sending data from an application at sender side to an
application at the destination side, sender must know the IP
address of destination and port number of the application (at the
destination side) to which he want to transfer the data. Block
diagram is shown below :
Multiplexing and Demultiplexing in Transport Layer
Multiplexing / Demultiplexing
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
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
sender receiver
side side
• a set of states
• a set of transitions between
those states
• actions in response to
events or transitions
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
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)
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) &&
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) &&
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) &&
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)
L
L
Wait for Wait for
ACK or call 1 from
rdt_rcv(rcvpkt) && NAK 1 above
( corrupt(rcvpkt) ||
isNAK(rcvpkt) ) rdt_send(data)
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) || L
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
• Go-back-N Protocol
• Selective Repeat Protocol
Pipelined Protocol
Its 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.
In Figure(b),
As long as thethe
sender
limiting
doesfactor
not send
is not
more
thewater
bucket
than
capacity,
the bucket
but can
the
In Figure(a), we see a thick pipe leading to a small-capacity
contain, carrying
internal no watercapacity
will be lost.
of the network.
receiver.
Causes/costs of Congestion: Scenario 1
Two senders, Two receivers
One router, Infinite buffers
No retransmission
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: lin = lout
transport-layer input includes retransmissions : l’ in >= lin
l in : original data
l'in: original data, plus l out
retransmitted data
Host A
A no buffer space!
Host B
Causes/costs of Congestion: Scenario 2
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
lin
timeout
copy lout
l'in
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
TCP Slow Start
An algorithm which balances Host A Host B
the speed of a network
connection.
TCP slow start is one of the
RTT
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 the receiver time
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.
Summary
Introduction about Transport Layer Services and Protocol
Multiplexing and Demultiplexing (Connection-less & Connection Oriented)
Connection less transport (UDP, Checksum)
Principles of Reliable Data Transfer(rdt 1.0, rdt 2.0, rdt 2.1, rdt 2.2, rdt 3.0)
Pipelined Protocol (GobackN, Selective Repeat)
Connection oriented transport (TCP)
Flow Control & Congestion Control
TCP Slow Start approach
Thank You