Computer Networks

Unit-3
Transport Layer
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 applicatio
n

between application processes transport

network
data link
running on different hosts. physical

lo
 A transport protocols run in end

gi
ca
l
systems.

en
d-
en
 Sender side: It breaks application

d
tr
a
messages into segments, then

ns
po
r
passes to network layer.

t
applicatio

 Receiver side: It reassembles n

transport
network
segments into messages, then data link
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 P1 application
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
host: source IP,port: B,80 C
dest IP,port: A,9157 source IP,port: C,5775
IP dest IP,port: B,80
address A
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 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
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
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
L 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
L 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
L
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)
L
L
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) && rdt_rcv(rcvpkt) &&
(corrupt(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) || 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

(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

PIPELINED PROTOCOL

• 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.

 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.
Go-back-N Protocol works
sender window (N=4)
012345678 send pkt0
012345678 send pkt1
send pkt2 receive pkt0, send ack0
012345678
send pkt3 Xloss receive pkt1, send ack1
012345678
(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
Go-back-N Visualization
SELECTIVE REPEAT
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
 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
012345678 send pkt0
012345678 send pkt1
send pkt2 receive pkt0, send ack0
012345678
send pkt3 Xloss receive pkt1, send ack1
012345678
(wait)
receive pkt3, buffer,
012345678 rcv ack0, send pkt4 send ack3
012345678 rcv ack1, send pkt5 receive pkt4, buffer,
send ack4
record ack3 arrived receive pkt5, buffer,
send ack5
pkt 2 timeout
012345678 send pkt2
012345678 record ack4 arrived
012345678 rcv pkt2;
record ack5 arrived
012345678 deliver pkt2,pkt3, pkt4, pkt5
send ack2
Q: what happens when ack2 arrives?
Selective Repeat Visualization
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-47

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 Control – Cont…

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
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
Causes/costs of Congestion: Scenario 2
 Idealization: Perfect knowledge about buffer space
 Sender sends only when router buffers available

lin : original data

copy lout
l'in: original data, plus
retransmitted data

A free buffer space!

finite shared output

Host B
link buffers
Causes/costs of Congestion: Scenario 2
 Idealization: Known loss
 Packets can be lost, dropped at router due to full buffers
 Sender only resends if packet known to be lost

lin : original data

copy lout
l'in: original data, plus
retransmitted data

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
copy
timeo lout
ut l'in

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
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 the 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.
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