Chapter 3
👉🏻 If you want to enjoy the full experience exploring this pdf, check it out here Chapter 3
Transport Services and Protocols
Provide logical communication between application processes running on different hosts
Logical communication: The two connecting sides; the sender and the receiver are logically
connected to each other by a direct link
In real life hosts may be hundreds of kilometers apart but in a logical view they are directly
connected
Transport protocols provides communication services directly to applications running on end
systems
Role of Transport Protocols:
Send side:
Breaks application-layer messages into smaller chunks called segments
Passes these segments to the network layer
Receive side:
Reassembles received segments into the original message
Delivers the reassembled message to the application layer
Transport protocol available to apps: TCP, UDP
Transport layer vs. Network layer
Network Layer → Provides logical communication between hosts
Transport Layer → Provides logical communication between processes
Multiplexing and Demultiplexing
Multiplexing
When a process sends data to transport layer through sockets, transport layer is going to:
multiplex the data and put it in segments
add information into the transport layer header that is going to be used later for demultiplexing
Chapter 3 1
Demultiplexing
When packets and datagrams are received at the host, demultiplexing happens, the transport layer will
use header information to deliver the content of the received segments to the correct socket
How demultiplexing works?
The host receives IP datagrams, each
datagram contain:
Source IP address
Destination IP address
One transport layer segment
Source port number
Destination port number
→ The photo represents a TCP/UDP segment format
Then the host is going to use the IP address and the port number to direct the segment to the correct
destination
Connectionless Demultiplexing (UDP)
When creating a datagram to be sent into a UDP socket, the datagram must specify:
Destination IP address
Destination port number
When receiving host receive the UDP segment:
It checks the destination port number
Then directs the UDP segment to the socket with that port number
When multiple datagrams are received at the same time but they are with the same destination port
numbers, they are directed to the same socket
Connection-Oriented Demultiplexing (TCP)
Here we have got a sending side and a receiving side
When we instantiate a TCP socket, it is identified by a four-tuple:
The source IP address
Chapter 3 2
The source port number (on the sending side)
The Destination IP address
The Destination port number (on the receiving side)
The receiver is going to use ALL the 4-tuple values to direct a segment to the correct socket
Server may support many simultaneous ( )مع بعض ف نفس الوقتTCP sockets:
Each of these sockets is:
identified by its own 4-tuple
associated with different connecting client/client process
While demultiplexing in TCP, even if the port number is the same and the segments have different
destinations, the 4-tuple values for each segment is unique, so they are going to be sent to their
correct different destinations
User Datagram Protocol (UDP)
UDP is a very simple -so called “no frills”, “bare bones”- internet transport protocol
It is so simple because it provides “best-effort” service
UDP sends segments with no guarantee it will get to the receiving side, UDP segments may be lost or
could be delivered out-of-order
There is no need for handshaking between the sender and the receiver → No need to have shared
state → So UDP is connectionless
Each UDP segment can be handled independently of the other segments
The UDP packet consists of 8 bytes
Why is there UDP?
No connection establishment delay (RTT - Round Trip Time)
No connection state between the sender and the receiver, so no one of them has to wait for the other
to be connected
As a result of the above features, the header size is small and there is little overhead
UDP does not provide congestion control
UDP can blast away as fast as it desires, will not face congestion
UDP is used in:
Streaming multimedia apps
they are tolerant to some data loss
But they are also rate sensitive so we can’t congestion control them too strongly
SNMP:
SNMP (Simple Network Management Protocol) is a critical protocol for network management
and monitoring, enabling administrators to efficiently manage devices
Its reliance on UDP ensures simplicity, speed, and low resource consumption
If reliable data transfer is needed in UDP,
Chapter 3 3
it is possible to build it in the application layer on top of UDP → So we can add reliability in the
application layer
Application-Specific Error Recovery:
Design error recovery strategies tailored to the application's requirements
UDP is defined in RFC 768 (RFC → Request For Comment)
UDP Segment header
The header only has 4 fields:
The source port number
The destination port number
The length field (needed to calculate
payload)
The checksum field
The body which contains the data (The payload)
UDP Checksum
The role of the UDP checksum is to detect errors which are the flipped bits in the transmitted
segment between sender and receiver
Lets look at an example to see how checksum works:
If the sender is sending two numbers, the sender sends the two numbers and also sends the sum
of the two numbers to the receiver (check sum)
When the receiver receives the two numbers and compute their sum and then check whether the
sum of these two is equal to the checksum sent by the sender
If they are different then there is a problem, if they are the same, then probably everything is
okay
On the sender side:
The sender treats the contents of the UDP segment that includes the UDP header fields and IP
addresses as sequence of 16-bit integers
add them together
takes the one’s complement sum of the segment contents
Chapter 3 4
puts that value in the UDP segment’s checksum field
Then drops the segment down to IP
On the receiver side:
The receiver computes the checksum of the received segment which also includes the header
and the IP addresses
Checks whether that computed checksum equals the checksum field in the segment
If they are:
Not equal → SURE there is an error
Equal → There might be no errors, but there also might be errors that are not detected
How to compute checksum?
add two 16-bit integers:
→ Regular binary addition
Then you are going to take that overflowing bit and add it to the sum
Then get the one’s complement of that sum to get the checksum (flip each 0 to 1, and each 1 to 0)
Notice that, bits can change from sender to receiver but checksum may not detect it!
Chapter 3 5
Principles of Reliable Data Transfer (RDT)
Reliable Service Abstraction
Here we have a sending process and a
receiving process and the sending process
simply wants to send data to the receiving
process through a reliable channel
The reliable channel is unidirectional
From the perspective of the application using the reliable data transfer protocol:
The communication may seem unidirectional, as the application is only concerned with
transferring data from the sender to the receiver
Reliable Service Implementation
The implementation is in the form of a transport layer protocol
There are two sides to that protocol; a sender side and a receiver side
Both are going to be connected over an unreliable channel
The goal of a reliable data transfer protocol is to provide reliability over an inherently unreliable
channel
The reliable data transfer protocol operates on top of this unreliable channel to add features like:
Ensuring all packets are delivered.
Reordering packets.
Detecting and recovering from errors.
Message exchanges between the protocol entities is bi-directional
The complexity of the sender and the receiver side of the protocol (the reliable data transfer protocol)
is going to depend on the unreliable (underlying) channel:
Can it lose messages?
Can it corrupt messages?
Chapter 3 6
Can data be reordered?
→ Depending on these characteristics the implementation of the reliable channel will differ
Underlying Channel with Bit Errors
The underlying channel may flip bits in packet
How to recover from this error?
Using checksum to detect bit errors
Using Acknowledgement (ACKs) by which the receiver explicitly tells the sender that packet
received OK
Using Negative Acknowledgements (NAKs) by which the receiver explicitly tells the sender that
the packet received has errors
Sender then retransmits the packet on the receipt of the NAK
Underlying channel may lose packets as well
Sender waits enough amount of time to get an ACK, if it didn’t get it it resends the packet
Corrupted ACK/NAK
If the sender receives a corrupted ACK/NAK from the receiver (it is like you’re talking to someone and
his reply is bla-bla-bla) → the sender cannot determine what has the receiver received
The sender cannot determine this is an ACK or a NAK so it doesn’t know whether the receiver has
received the packet or there is an error
If the sender decides to retransmit, a duplication might happen at the receiver side as it might have
received the packet already
How to handle all this?
The sender will retransmit the packet if ACK/NAK is corrupted
Sender adds a sequence number to each packet so that the receiver can detect duplicates
If the sender sends a retransmission then it is sending a packet with the same sequence
number
If the receiver received a duplicate will not deliver it up to the application layer
→ This handling can be done using ACKs only
How It Works
Sender:
1. The sender transmits a packet with a sequence number
2. It waits for an ACK from the receiver that explicitly includes the sequence number of the last correctly
received packet
3. If an ACK is not received within a timeout, or if a duplicate ACK is received, the sender retransmits the
current packet
Chapter 3 7
Receiver:
1. When the receiver receives a packet:
If the packet is correct (no errors, in sequence), it sends an ACK with the sequence number of the
received packet
If the packet is incorrect (out of order, lost, or corrupted), it repeats the last ACK for the last
correctly received packet
2. This duplicate ACK notifies the sender that the next expected packet was not received correctly
Underlying Channels with errors and loss
Underlying channel can also lose packets; data or ACKs
How to Handle this?
The sender is going to wait a certain amount of time to get an ACK
If it didn’t get it in that time, it is going to retransmit the packet
To avoid retransmission duplicates, sequence number is included with sent packets
Also the receiver will include the sequence number of the ACKed packet
Requires a countdown timer to tell the sender when the amount of time it has to wait is over
Reliable Transmission in Action
Case 1: No Loss
In this case, the sender sends all the packets
with no lost packets and the receiver sends all
the ACKs with no loss or delay
Chapter 3 8
Case 2: Packet Loss
In this case:
when the sender sends packet 1 it gets
lost before the receiver gets it
After the countdown timer times out and
the receiver gets nothing, the sender is
going to send the packet again and the rest
of the transmission goes on
Case 3: ACK Loss
In this case:
When the receiver sends the ACK of
packet 1, it gets lost before the sender gets
it
After the countdown timer times out and
the sender gets nothing, the sender is
going to send the packet again
When the receiver receives packet 1 again,
it doesn’t upload it to the server, it just
sends its ACK
Then the transmission goes on
Case 4: Delayed ACK
In this case:
when the sender sends packet 1, it was
waiting for the ACK
The timeout passed and the ACK was not
sent to the sender
The sender sends packet 1 again
after sending packet 1 again the sender
receives the ACK of it so it sends the
packet after it which is packet 0
when the receiver receives packet 1 again
it detects duplicate and doesn’t upload it to
the server and send ACK 1 again to the
sender
Chapter 3 9
When the sender gets ACK 1 again it
ignores it because it has already got it and
know it is a duplicate now
Stop and Wait Operation
Utilization: Usender → The fraction of time sender is busy sending packets
At t = 0, the sender transmits the first bit of the packet
L
At t = R , the last bit is transmitted into the channel
The ACK arrives after RTT
So the whole time for the packet to be sent and the ACK to be received is t = RTT + L
R
L/R
The utilization is: Usender
= RTT +L/R
→ This equation determines how much the user is busy sending,
If RTT is high relative to L/R then there is high delay or low transmission speed
If RTT is low relative to L/R then the sender is sending most of the time and the utilization
approaches to 1
→ So - if Usender approches to 1 → this is good
- If it is a small or very small fraction → this sender is not doing a good job
Hard utilization is because of the stop and wait behavior of the RDT protocol
Pipelined Protocol
Pipelining: Sender allows multiple “in-flight” yet-to-be-acknowledged packets
→ this means:
It allows the sending of multiple packets at the same time without waiting to get the ACK of each
one
Range of sequence numbers will increase
Buffering at sender and receiver will increase
If we increased the number of packet to be sent at the same time to N, the utilization will increase by a
factor of N
There are two types of pipelined protocols:
Go-Back-N
Selective Repeat
Go-Back-N: Sender
The sender is allowed to have a window of up to N transmitted packets without being ACKed
Chapter 3 10
and will need to include sequence numbers of K-bit in the packet header
Go-Back-N operates on:
A cumulative ACK acknowledges all packets up to and including sequence number NNN.
For example:
If the sender receives ACK(5) , it knows that packets 1, 2, 3, 4, and 5 have been received
correctly by the receiver.
Any packets with sequence numbers greater than 5 still need acknowledgment.
When the sender receives ACK(n) it shifts the window to start at sequence number n+1,
allowing it to send new packets
In the previous example, it would shift the window to packet number 6
There is a timer for oldest in-flight packet
When timer times out, the sender is going to retransmit all packets starting from in to all higher
sequence number packets in the window
Go-Back-N: Receiver
The receiver is going to send ACK for the correctly-received packet that has the highest in-order
sequence number
When it receives out of order packet:
it is going to re-ACK the packet with the highest in-order sequence number
it can buffer discard the duplicate or buffer it but that’s an implementation decision
The receiver’s view of the sequence numbers space (window) is very simple:
it just tracks the sequence number of the next in-order packet expected to be received
it does this using rcv_base
Selective Repeat
The receiver individually acknowledges all correctly received packets and can buffer packets for
eventual in-order delivery to upper layer
The sender maintains a timer for each individual unacknowledged packet, when it times out it
retransmits that individual packet
Window view of sender and receiver:
Chapter 3 11
On the sending side, there is a window with size N, within that window there will be sequence
numbers corresponding to packets as shown in the colors in the image above
On the receiver side:
On the left of the window we have sequence numbers corresponding to packets that have already
been ACKed
The window begin with a Seq. number of an expected packet but not yet received
Then the red packets are out of order
and the blue packets are acceptable
Connection-Oriented Transport (TCP)
TCP is defined in RFCs 793, 1122, 2018, 5681, 7323
TCP operates in a point-to-point manner → between one sender and one receiver
It provides reliable in-order byte stream → no message boundaries
TCP is full duplex meaning that data payloads can flow in both directions
The payload which is contained has a maximum segment size (MSS) → typically
TCP uses cumulative ACKs as in Go-Back-N
TCP is a pipelined protocol
its congestion and flow control determines window size
It is connection-oriented → requires handshaking between sender and receiver before data exchange
The flow control prevents the sender from overwhelming the receiver
The TCP packet has minimum size of 20 bytes and maximum 60 bytes
Chapter 3 12
TCP Segment Structure
The TCP segment is 32 bits
The source port number used for multiplexing
The destination port number used for demultiplexing
32-bits sequence number
32-bits ACK number
Internet checksum
RST, SYN, FIN bits are used for connection management
The receive window → used for flow control, the receiver tell the sender the number of bytes it’s
willing to accept
The PSH bit indicates that the sender is requesting the receiver to deliver the data to the application
The Urgent data pointer field and URG bit are not really used
A set of options, a variable number of options can be included → that makes the header with variable
length
The application data (The payload carried)
TCP Sequence, ACK Number
TCP implements byte stream abstraction
The sequence number carried in the sequence number field in TCP header indicates the byte stream
number of the first byte in that segments payload data
The Acknowledgment field is used by the receiver to tell the sender the sequence of the next byte that
is expected to be received from the sender
That number serves as an accumulative ACK for all bytes of data that has occurred before that
sequence number
TCP has no specifications with out of order data → up to the implementation
Chapter 3 13
Notice that:
The TCP ACK number on the second arrow is more than the seq. number on the first arrow by one
The TCP ACK number on the third arrow is more than the Seq. number on the second arrow by
one
The Seq. number on the third arrow is more than that on that first arrow by one
TCP Retransmission Scenarios
Lost ACK
In this scenario,
A TCP segment is transmitted but the ACK
is lost
After time is out, another segment is
transmitted then reACKed
ACK Delay
In this Scenario,
The TCP segments are sent and ACKed but
the ACKs are received after the timeout of
the sender
So the sender retransmits the segment but
the receiver has already received the
segment so it sends a cumulative ACK for
both segments
Chapter 3 14
Cumulative ACK
In this Scenario,
The first ACK is lost but the second one
(cumulative) is received so the sender can
then transmit the third signal knowing that
the first two segments has arrived
TCP Flow Control
This diagram shows a typical transport layer
presentation:
A segment is brought up the protocol stack
to the transport layer
The segment’s payload is removed from
the segment and written into the socket
buffers
An application program will perform a
socket read and that will remove data from
the socket buffers
Flow Control is a mechanism to avoid the sender to overflow the receiver’s buffer by transmitting too
much, too fast
The receiver informs the sender how much free buffer space there is
The sender will be limited to send no more than this amount of data
The limit set by the receiver is shown in the rwnd field in TCP header (receive window)
Connection Management
Before Exchanging the data, sender and receiver must handshake:
Agree to establish connection
Agree on connection parameters
This agreement is done through Handshaking
Chapter 3 15
2-Way Handshake Scenarios
Half open connection
In this Scenario,
The client asks the server for a connection
The server accepts and establish the
connection
but the the establish response reached the
client late
so the client sends another request for
connection
The server accepts and responds to the
connection but the client has already
closed the connection so there is no client!
Duplicate data
This scenario is similar to the previous one, but
this time there is a retransmitted piece of data
in the initial connection that appears in the
receiving side after the connection has closed
The server accepts the retransmitted
connection state and establish a new
connection
and then accepts the received message, it
has an open connection and a correct
sequence number, so why not
Accepting a message twice would result in
big problems
→ Using 2-Way Handshaking has some short comes and this is why TCP uses 3-Way handshake!
By: Malak Amr
Chapter 3 16