The document summarizes key aspects of the transport layer from Chapter 3 of the textbook "Computer Networking: A Top Down Approach". It discusses the goals of the transport layer, including providing multiplexing/demultiplexing, reliable data transfer, congestion control and flow control. It then describes the two main Internet transport protocols - UDP (connectionless) and TCP (connection-oriented), focusing on their differences and how TCP provides reliability.

1. Chapter 3
Transport Layer
Computer Networking:
A Top Down Approach,
4th edition.
Jim Kurose, Keith Ross
Addison-Wesley

2. Chapter 3: Transport Layer
Our goals:
 Understand principles
behind transport layer
services:




Multiplexing/De-multiplexing
Reliable data transfer
Congestion control
Flow Control
 Learn about transport
layer protocols in the
Internet:





UDP: connectionless
transport
TCP: connection-oriented
transport
TCP Reliability
TCP congestion control
TCP Flow Control

3. Transport Services and Protocols
 Transport layer protocols provide
logical communication between app
processes running on different hosts
 From application’s perspective as
if the host running the process
are directly connected
 Transport protocols run in end
systems
 Not in routers
 Sender side: Breaks app
messages into segments, passes
to network layer
 Receiver side: Reassembles
segments into messages, passes
to application layer
 More than one transport protocol
available to applications
 Internet: TCP and UDP
application
transport
network
data link
physical
application
transport
network
data link
physical

4. Transport vs. Network layer
Network layer: logical communication between hosts
 Transport layer: logical communication between

processes
Household Analogy:

12 kids sending letters to 12 kids
 processes = kids
 app messages = letters in envelopes
 hosts = houses
 transport protocol = Ann and Bill
 network-layer protocol = postal service
 Transport layer relies on Network layer

5. Internet Transport Layer Protocols
 Internet Protocol (IP)
Best effort delivery service
 No guarantees for segment delivery
 No guarantees for orderly delivery of data
 IP is unreliable service
Extending Host-to-Host delivery to process-to-process delivery.
 Transport layer Multiplexing and De-multiplexing
UDP and TCP also provide integrity checking by including error
detection field in their segment headers.
UDP services

Process to process data delivery

Error checking
TCP Reliable data Transfer
 Congestion Control, sequence numbers, acknowledgements and
timers






6. Multiplexing/De-Multiplexing
 Every process has a socket which allows

Data to pass from the network to the process

Data to pass from the process to the network
 Receiving host directs an incoming transport layer
segment to appropriate socket.

Uses set of fields in the transport layer segments
 Delivering data in the transport layer segment to the
correct socket is called de-multiplexing.
 Gathering data chunks at the source host from
different sockets ,appending header information and
passing to the network layer is called multiplexing
 Household analogy

7. Multiplexing/De-multiplexing
Demultiplexing at rcv host:
delivering received segments
to correct socket
= socket
= process
application P3
P1
P1
application
transport
transport
network
network
link
physical
P4
application
link
physical
Multiplexing at send host:
gathering data from multiple
sockets, enveloping data with
header (later used for
demultiplexing)
host 1
P2
transport
network
link
physical
host 2
host 3

8. How De-multiplexing works
 Sockets have unique
identifier
 Each segment has special
field that indicate the socket
to which the segment is to be
delivered
 Source port number
 Destination port number
 Port is a 16 bit number
0 to 65535
0 to 1023 are well
known port numbers
and are reserved
32 bits
Source Port #
Dest Port #
Other Header Fields
Application
Data
(message)
Transport Layer Segment Format

9. Connectionless Transport:UDP






Internet transport protocol RFC 768
UDP does just about as little as a transport layer protocol can
do
Multiplexing/De-multiplexing
Error checking
“Best Effort” service, UDP segments may be:
 lost
 delivered out of order to applications
Connectionless:


No handshaking between UDP sender, receiver
Each UDP segment handled independently of others

10. Connectionless Transport:UDP
Why is there a UDP?
 No connection establishment


TCP uses a three way handshake
UDP has no delay to establish a connection
 DNS uses UDP
 No connection state at sender, receiver


TCP maintains connection state
 Congestion control parameters, sequence numbers etc.
UDP maintains no connection state
 Server can support many more active clients with UDP than over TCP
 Small segment header


20 bytes of header in TCP
Only 8 bytes of header in UDP
 No congestion control

UDP can blast away as fast as desired

11. UDP: Segment Structure
 The application data
occupies the data field of
the UDP segment.
 UDP header has four fields
 Each of two bytes
 Checksum
 Used by receiving host
to check for errors in
the segment
 Length
 Length of the UDP
segment
Length, in
bytes of
UDP
segment,
including
header
source port #
dest port #
length
checksum
Application
data
(message)
UDP segment format

12. Connectionless (UDP) De-multiplexing
P2
SP: 6428
SP: 6428
DP: 9157
client
IP: A
P1
P1
P3
SP: 9157
DP: 6428
DP: 5775
server
IP: C
SP provides “return address”
SP: 5775
DP: 6428
Client
IP:B

13. UDP Checksum
Checksum is used to determine whether bits within the UDP
segment have been altered e.g. noise in the link.
Sender:
 Treat segment contents
as sequence of 16-bit
word
 Checksum: 1’s complement
of the sum of all the 16bit words.
 Sender puts checksum
value into UDP checksum
field
Receiver:
 All segments are added and
than sum is added with
sender's checksum.
 If no errors are introduced
into the packet, then clearly
the sum at the receiver will
be all 1’s.
 If receiver side checksum
contains any 0 then, error is
detected and the packet is
discarded.

14. Checksum Example
(16 bits segment) 0110011001100110
0101010101010101
0000111100001111
The sum of first of these 16-bits integer is:
0110011001100110
0101010101010101
1011101110111011
Adding the third one to the above sum gives
1011101110111011
0000111100001111
1100101011001010 (sum of all segments)
The checksum at sender side is : 0011010100110101 (1’s
complement).
 Now at the receiver side, again all segments are added and
sum is added with sender's checksum.
 If no error than check of receiver would be :
1111111111111111

15. Checksum Example
 Note

When adding numbers, a carryout from the
most significant bit needs to be added to the
result
 Example: Add two 16-bit words
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 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 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

16. Home Assignment
 Difference between UDP and UDP Lite?

17. Principles of Reliable Data Transfer
• Important in application, transport, link layers
• Top-10 list of important networking topics!

18. Principles of Reliable Data Transfer (rdt)
• Important in application, transport, link layers
• Top-10 list of important networking topics!

19. Principles of Reliable Data Transfer
• Important in application, transport, link layers
• Top-10 list of important networking topics!

20. Reliable Data Transfer: Getting Started
rdt_send(): called from
above, (e.g., by app.). Passed data to
deliver to receiver upper layer
send
side
udt_send(): called by rdt
protocol, to transfer packet over
unreliable channel to receiver
deliver_data(): called by rdt
to deliver data to upper layer
receive
side
rdt_rcv(): called when packet
arrives on rcv-side of channel

21. Reliable Data Transfer: Getting Started
We’ll:
• 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
determined by next
event
state
1
event
actions
state
2

22. Rdt1.0: Reliable Data Transfer over a Perfectly
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 read data from underlying channel
• The initial state of the FSM is indicated by the dashed line
Wait for
call from
above
rdt_send(data)
packet =make_pkt(data)
udt_send(packet)
Sender
Wait for
call from
below
rdt_rcv(packet)
extract (packet,data)
deliver_data(data)
Receiver
Note:Perfectly reliable channel no need for feedback

23. Rdt2.0: Channel with Bit Errors
• More realistic model
– Underlying channel may flip bits in packet
• How people deal with such a situation
– OK (positive acknowledgment)
– Please repeat that (negative acknowledgements)
– 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
• These control messages let the receiver know
– What has been received in error and requires repetition
• Automatic Repeat reQuest (ARQ) protocols.

24. Rdt2.0: Channel with Bit Errors
Three capabilities are required in ARQ to handle the presence of bit
errors.
• Error Detection:
– Needed to allow the receiver to detect bit errors
– Checksum field in the header
• Receiver Feed Back
– Receiver provided explicit feedback
– ACK
– NAK
• Retransmission
– A packet that is received in error will be retransmitted
• New mechanisms in rdt2.0 (beyond rdt1.0):
– Error detection
– Receiver feedback: Control msgs (ACK,NAK) Rcvr->Sender

25. Rdt2.0: FSM Specification
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for
call from
above
Wait for
ACK or
NAK
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
receiver
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
Wait for call
from below
sender
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

26. Rdt2.0: Operation with No Errors
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for call
from above
Wait for
ACK or
NAK
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
Wait for call
from below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

27. Rdt2.0: error scenario
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for
Wait for call
from above
ACK or
NAK
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
Wait for call
from below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

28. Rdt2.0
• rdt2.0 is a stop and wait protocol
– Sender sends one packet, then
waits for receiver response
• rdt2.0 has a fatal flaw
• What happens if ACK/NAK get
corrupted?
–
•
Add checksum bits to ACK/NAK
How the protocol should recover from
errors in ACK/NAK?
– Retransmission on receipt of a
corrupt ACK/NAK
– Retransmission causes duplicates
– Receiver does not know whether
ACK or NAK it sent was received
correctly
– Receiver does not know a priori
whether an arriving packet
contains new data or is a
retransmission
Handling Duplicates:
• Sender retransmits current
packet if ACK/NAK garbled
• Sender adds sequence number
to each packet
• Receiver discards (doesn’t
deliver up) duplicate packet