Module 4

Transport Layer

Contents

• Introduction
• Transport-Layer Protocols: Introduction
• User Datagram Protocol
• Transmission Control Protocol: services, features, segments, TCP connections, flow control, Error control, Congestion control

Introduction

• The transport layer is situated between the application layer and the network layer.
• It provides process-to-process communication between two application layers (local and remote hosts).
• Communication is achieved via a logical connection, enabling the two application layers to communicate as if there were a direct link.
• This logical connection allows sending and receiving messages globally, regardless of physical location.

• On a computer, a web browser process communicates with a web server process over the Internet using HTTP. Here, the browser and server are specific processes, not just the computers themselves.

Process-to-process communication = Data transfer between specific programs running on computers, not just between the computers themselves.

Introduction

Introduction

1. Figure 23.1 illustrates a logical connection at the transport layer, similar to the physical layer scenario in Chapter 3 (Figure 3.1).

​

• Alice’s host (Sky Research) and Bob’s host (Scientific Books) establish a logical connection through the transport layer.

​

• The two companies communicate as if a real connection exists between them at the transport layer.

​

• Only Alice’s and Bob’s computers utilize transport layer services, while intermediate routers use only the first three layers (physical, data-link, network).�

Introduction

The transport layer communicates by helping data move reliably and efficiently between two devices.�

1. Breaks data into segments – The transport layer divides large data from the application layer into smaller parts (segments) for easier transmission.
2. Adds headers – Each segment gets a header with source and destination port numbers to identify which application it belongs to (like a web browser or email app).
3. Establishes connection – In TCP, it sets up a reliable connection between sender and receiver using a process called three-way handshake.
4. Transfers data – It sends data segments one by one and ensures they reach correctly.
5. Checks errors and reorders data – Lost or out-of-order packets are detected and corrected.
6. Reassembles data – The receiver’s transport layer joins all segments back into the original message.

Transport-Layer Services

• Process-to-Process Communication: Ensures messages are delivered to the correct application process on the destination device.
• Multiplexing and Demultiplexing: Supports multiple applications by assigning port numbers, allowing multiple processes to share a single network connection.
• Error Control: Detects and corrects errors to ensure data integrity during transmission.
• Flow Control: Manages the data flow rate between sender and receiver to prevent overwhelming the receiver.
• Congestion Control: Helps manage network traffic to prevent congestion, adjusting the data rate as needed.

Transport-Layer Services

​

• Connection Management: Establishes, maintains, and terminates logical connections between hosts, crucial for reliable data transfer (used by TCP).
• Data Segmentation and Reassembly: Divides large messages into segments for transmission and reassembles them at the destination.

Transport-Layer Services

Transport-Layer Services

User Datagram Protocol

• The User Datagram Protocol (UDP) is a connectionless, unreliable transport protocol.

​

• UDP takes messages from the application process, attaches source and destination port number fields for the multiplexing/demultiplexing service, adds two other small fields(length of header and checksum), and passes the resulting segment to the network layer.

​

• If the segment arrives at the receiving host, UDP uses the destination port number to deliver the segment’s data to the correct application process.

​

Many applications are better suited for UDP for the following reasons:

1) Finer application-level control over what data is sent, and when:

Under UDP, as soon as an application process passes data to UDP, UDP will package the data inside a UDP segment and immediately pass the segment to the network layer(Source & destination port no, length and checksum)

2) No connection establishment:

TCP uses a three-way handshake to establish the connection before it starts to transfer data. UDP just sends the data without any formal preliminaries. Thus, UDP does not introduce any delay to establish a connection.

​

User Datagram Protocol

User Datagram Protocol

3) No connection state:

• TCP maintains connection state such as receive and send buffers, congestion-control parameters, and sequence and acknowledgment number parameters.
• UDP, on the other hand, does not maintain connection state and does not track any of these parameters. For this reason, a server using UDP can handle many more users at the same time than a server using TCP, since it doesn’t have to spend time and memory managing connections.

​

4) Small packet header overhead:

The TCP segment has 20 bytes of header overhead in every segment, whereas UDP has only 8 bytes of overhead.

​

​

Many applications are better suited for UDP for the following reasons:

User Datagram Protocol – Segment structure

UDP sends data in packets called user datagrams.� Each packet has a small header of 8 bytes, divided into 4 parts, each 2 bytes long.

• Port numbers: Help the receiver send the data to the right application or program.
• Length: Shows the total size of the UDP packet (header + data).
• Checksum: Helps check for errors during data transfer.
• Data field: Contains the actual message sent by the application

• 0 to 31 show bit positions, not the size of the header.
• They are only used to label where each part of the header starts and ends.

User Datagram Protocol

The following is the content of a UDP header in hexadecimal format.

​

a. What is the source port number?

b. What is the destination port number?

c. What is the total length of the user datagram?

d. What is the length of the data?

e. Is the packet directed from a client to a server or

vice versa?

f. What is the client process?

UDP Packet Structure

A UDP packet = Header + Data

• Header: Always 8 bytes (4 fields × 2 bytes each)
• Source port → 2 bytes
• Destination port → 2 bytes
• Length → 2 bytes
• Checksum → 2 bytes
• Data: The actual message from the application.
• Length = Total length − Header length

CB84000D001C001C

User Datagram Protocol

Solution

1. The source port number is the first four hexadecimal digits (CB84)16 or (52100)10.
2. The destination port number is the second four hexadecimal digits (000D)16, the destination port number is (13)10.
3. The third four hexadecimal digits (001C)16 define the length of the whole UDP packet as (28)10 bytes.
4. The length of the data =28 − 8 = 20 bytes, because packet header is always 8 bytes
5. Checksum (last 4 hexdecimal digits = 2 bytes) is (001C)16 - (28)10
• Source port = 52100 → that’s the client, Destination port = 13 → that’s the server
• Because the packet is going to port 13, it means the message is going from the client to server.

CB84000D001C001C

UDP Services

1. Process-to-Process Communication

UDP uses socket addresses (IP address + port number) to facilitate communication between specific processes.

2. Connectionless Services

No connection setup or termination.

Each datagram is independent and may take different paths.

Best for small messages (up to 65,507 bytes including headers).

3. No Flow Control

UDP does not manage data flow.

The sender might send messages faster than the receiver can handle, causing the receiver to become overloaded.

​

UDP Services

4. Error Control

Limited to a checksum for detecting errors.

No retransmission for lost or corrupted data;

faulty datagrams are discarded.

5. Checksum

UDP checksum helps detect errors in the data.

It checks three parts:

• Pseudo header – some important fields from the IP header (source and destination IP)
• UDP header – the 8-byte header itself (details about which application should get data)
• Application data – the actual message being sent

UDP Services

Why Include the Pseudoheader?

• The pseudoheader helps ensure the packet is delivered to the correct host and protocol (UDP or TCP).
• If the IP header is corrupted, a packet might be sent to the wrong host.
• The protocol field in the pseudoheader ensures the packet belongs to which protocol (value of protocol for UDP: 17 and for TCP : 6, to specify type of protocol).
• If this value changes during transmission, the receiver detects it, and UDP discards the packet.

Optional Checksum

• UDP checksum is optional, meaning it can be set to 0 to indicate that no checksum calculation is performed. Unlike TCP, the UDP checksum is not compulsory.

UDP Services

6. Congestion Control

UDP does not manage network congestion because it is connectionless.

It assumes packets are small and irregular, but this may not always be true (e.g., with real-time audio or video).

​

7. Encapsulation and Decapsulation

Encapsulation: UDP wraps data into packets (user datagrams) for sending.

Decapsulation: UDP unwraps received packets to extract the data.

UDP Services

8. Queuing

UDP uses queues for handling messages at ports:

Incoming queue: For messages arriving at the port.

Outgoing queue: For messages waiting to be sent (in some implementations).

​

9. Multiplexing and Demultiplexing

Multiplexing: Allows multiple processes to send data through a single UDP service.

Demultiplexing: Ensures the correct process receives the data by using port numbers.

UDP Services

Comparison with a Simple Protocol

​

A simple protocol means a protocol that is very basic and doesn’t do extra things like:

• Establishing a connection before sending data
• Ensuring the data is received correctly
• Resending lost packets

​

UDP is similar to a basic connectionless protocol but adds an optional checksum.

If the checksum detects corruption, the packet is discarded without notifying the sender.

Advantages of UDP

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

Disadvantages of UDP

• No reliability: UDP does not guarantee delivery of packets or order of delivery, which can lead to missing or duplicate data.
• No congestion control: UDP does not have congestion control, which means that it can send packets at a rate that can cause network congestion.
• Vulnerable to attacks: UDP is vulnerable to denial-of-service attacks , where an attacker can flood a network with UDP packets, overwhelming the network and causing it to crash.
• 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.

Typical Applications

• UDP is suitable for a process that requires simple request-response communication with little concern for flow and error control.
• UDP is suitable for a process with internal flow- and error-control mechanisms.
• UDP is a suitable transport protocol for multicasting.
• UDP is used for management processes such as SNMP(Simple Network Management Protocol).
• UDP is used for some route updating protocols such as Routing Information Protocol (RIP).
• UDP is normally used for interactive real-time applications that cannot tolerate uneven delay between sections of a received message.

Connection-Oriented Transport: TCP

• The TCP Connection TCP is said to be connection-oriented because connection has to be established between two application processes before they start transmitting data.

​

• As part of TCP connection establishment, both sides of the connection will initialize many TCP state variables associated with the TCP connection.

​

• A TCP connection provides a full-duplex service: If there is a TCP connection between Process A on one host and Process B on another host, then application layer data can flow from Process A to Process B at the same time as application layer data flows from Process B to Process A.

Connection-Oriented Transport: TCP

• A TCP connection is always point-to-point, that is, between a single sender and a single N receiver. Multicasting is not allowed.
• Once a TCP connection is established, the two application processes can send data to each other.
• Let’s consider the sending of data from the client process to the server process.
• The client process passes a stream of data through the socket.
• Once the data passes through the door, the data is in the hands of TCP running in the client.
• TCP segments the data, adds headers, and ensures reliable delivery. The data is then transmitted via IP and reassembled by TCP on the server side before being passed to the server application.

TCP Services

1. Process-to-Process Communication: TCP uses port numbers to enable communication between specific processes, just like UDP.

​

2. Stream Delivery Service: TCP ensures that the data is delivered in the correct order, without errors, and without duplication, providing a full-duplex, byte-stream communication between the sender and receiver.

• It creates an imaginary "tube" between the

sender and receiver, allowing seamless data flow.

TCP Services

3. Sending and Receiving Buffers

TCP uses buffers to manage data flow:

Sending Buffer: Holds data that is sent but not yet acknowledged.

Receiving Buffer: Stores incoming data until the receiving process reads it. Buffers use a circular array for efficient recycling of storage.

TCP Services

4. Segments

Data from the buffer is grouped into segments (packets) with added headers for control.

Segments can vary in size and may be lost or arrive out of order, but TCP handles these issues transparently.

TCP Services

5. Full-Duplex Communication

• TCP supports two-way data flow simultaneously, with separate buffers for sending and receiving at each endpoint.

6. Multiplexing and Demultiplexing

• TCP manages multiple processes by using port numbers to direct data to the correct application.
• Connections are required for each communication pair.

TCP Services

7. Connection-Oriented Service: Communication happens in three steps:

• Connection Setup: A logical connection is established.
• Data Exchange: Data flows in both directions.
• Connection Termination: The connection is closed.

This ensures reliable and ordered delivery.

8. Reliable Service

• TCP uses acknowledgments to confirm data is received correctly.
• Lost, corrupted, or out-of-order segments are detected and resent to ensure reliability.

TCP Features

Numbering System

TCP uses byte numbers instead of segment numbers for tracking data.

The sequence number and acknowledgment number fields in the TCP header refer to byte numbers.

​

Sequence Numbers:

• TCP assigns a number to every byte of data sent.
• Example: If the first byte is numbered 1000, the next byte is 1001, and so on.

Acknowledgment Numbers:

• The receiver sends back a number to confirm it got the data.
• Example: If it received bytes up to 1500, it sends "1501" as the next expected byte.

​

TCP Features

Sequence Number

• Each TCP segment gets a sequence number: The first segment’s sequence number is the Initial Sequence Number (ISN), a random starting value.
• For later segments, the sequence number is the previous segment’s sequence number plus the number of bytes sent in that segment.
• Even control-only segments (e.g., connection setup) consume a sequence number for tracking purposes.

​

Example: Sending a file of 3000 bytes in 3 segments (1000 bytes each) starting with ISN = 10001:

Segment 1: 10001 (Bytes: 10001–11000)

Segment 2: 11001 (Bytes: 11001–12000)

Segment 3: 12001 (Bytes: 12001–13000)

Segement 1: Last byte = ISN + number of bytes − 1

Segment 2: First byte = last byte of previous segment + 1

= 11000 + 1 = 11001

TCP Features

Acknowledgement Number

TCP is full-duplex, meaning both sides can send and receive simultaneously.

The acknowledgement number tells the sender, "I’ve received all bytes up to this number - 1 safely.

The acknowledgement number is cumulative, meaning it confirms receipt of all prior data.

Example: If the receiver sends an acknowledgement number 5643, it means all bytes from the start up to 5642 have been received correctly.

TCP Segment Structure

The TCP segment

• The TCP segment consists of header fields and a data field.
• The data field contains a chunk of application data.
• The minimum length of TCP header is 20 bytes.
• 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
• Reserved bits: These bits are not currently used in normal TCP operation. Used for future extension.

​

The TCP segment

• Window size. TCP segment tells the receiver how many bytes it can accept from the sender without sending an acknowledgment.

​

• 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 optional and variable-length options field is used when a sender and receiver negotiate the maximum segment size (MSS) or as a window scaling factor for use in high-speed networks.

​

The TCP segment consists

• Checksum. This 16-bit field contains the checksum. The TCP checksum makes sure the data is not damaged or changed while being sent. If an error is found, the segment is discarded.

The TCP segment

URG: The Urgent Pointer helps the receiver identify data that should be processed immediately. A bit in the TCP header that, when set to 1, indicates the Urgent Pointer field is in use.

ACK: Confirms the receipt of data by acknowledging the next sequence number expected.

PSH (Push): Instructs the receiving system to push the data to the application layer immediately, rather than waiting to fill up the buffer.

RST (Reset): Used to reset the connection when an error is detected or an invalid segment is received.

SYN (Synchronize): Initiates a connection and synchronizes sequence numbers between sender and receiver.

FIN (Finish): Signals the intent to terminate the connection gracefully.

​

​

​

​

​

Phases of a TCP Connection

Connection Establishment (Three-Way Handshaking)

• Before data transfer, TCP sets up a connection using a process called three-way handshaking.

Phases of a TCP Connection

Connection Establishment (Three-Way Handshaking)

This involves the following steps:

​

Step 1: SYN

• The client sends a SYN (synchronize) segment to the server.
• This contains a random starting sequence number (ISN) and requests to establish a connection.

​

Step 2: SYN + ACK

• The server responds with a SYN + ACK segment.
• The SYN part sets the server’s own sequence number, and the ACK part acknowledges the client’s SYN.
• The server also shares its available receive window size.

​

Phases of a TCP Connection

Connection Establishment (Three-Way Handshaking)

Step 3: ACK

• The client sends an ACK to confirm the server’s SYN + ACK.
• Optionally, it may include the first piece of data.
• The connection is now established, and data transfer can begin.

​

SYN Flooding Attack

• An attacker sends many fake SYN packets using spoofed IP addresses.
• The server allocates resources for these fake requests and waits for responses that never arrive.
• This overloads the server, preventing it from handling real requests

​

Phases of a TCP Connection

Data Transfer

• Bidirectional Transfer: After connection

establishment, data and acknowledgments can flow in both directions. Acknowledgments can be piggybacked(Acknowledgments can be combined with outgoing data ) on data segments.

​

Phases of a TCP Connection

Data Transfer

• Pushing Data: Used to immediately deliver data to the receiving application(Don’t wait to fill the buffer)

The PSH (push) flag can be used when immediate delivery of data is required, bypassing normal buffering to ensure timely transmission and reception.

• Urgent Data: Used for high-priority data

Urgent data, marked with the URG flag, signals that certain bytes need special attention by the receiving application. The urgent pointer shows where the urgent data ends in the segment.

Phases of a TCP Connection

TCP Connection Termination

​

Phases of a TCP Connection

TCP Connection Termination

Half-Close:

• One side (e.g., the client) stops sending data by sending a FIN, but can still receive data.
• The other side (e.g., the server) acknowledges the FIN with an ACK and continues sending data if needed.
• Once done, it sends a FIN, which is acknowledged by the client to complete the process.

Connection Reset:

• A connection can be forcefully terminated using the RST flag, typically to deny a request, abort a connection, or terminate an idle session.

Windows in TCP

TCP uses two types of windows for each direction of data transfer:

1. Send Window and
2. Receive Window.

Each plays a crucial role in managing data flow, error recovery, and congestion control.

​

Send Window:

• Represents the range of data bytes the sender can send without waiting for an acknowledgment.
• It adjusts dynamically based on the receiver's advertised window size (flow control) and network congestion.
• Uses a single timer for retransmissions.

Windows in TCP

Send Window:

​

Windows in TCP

Receive Window:

​

• How much data the receiver can handle at a time.
• Helps the sender control the flow by using the receiver’s window size (called rwnd).
• Changes depending on how much free space is left in the receiver’s buffer.
• rwnd = buffer size − bytes still waiting to be processed.
• Uses ACKs to tell the sender which byte to send next.

​

• SACK (Selective Acknowledgment) improves this by telling exactly which parts of data arrived .

I got bytes 1000–1500 and 2000–2500, but missed 1500–2000.

Windows in TCP

Receive Window:

​

Flow control

Flow control ensures the sender does not overwhelm the receiver by sending data faster than the receiver can process it. TCP achieves this by using a receive window (rwnd), which is a field in TCP headers that tells the sender how much more data the receiver can handle.

​

Flow control

In TCP flow control:

Data Paths (1, 2, and 3):

• Data flows from the sending process to the sending TCP,
• From the sending TCP to the receiving TCP,
• Finally, from the receiving TCP to the receiving process.

Flow Control Feedback (Paths 4 and 5):

• Path 4: Feedback travels from the receiving TCP to the sending TCP to inform how much data the receiver can handle (via the receive window size, rwnd).
• Path 5: If the sending TCP's buffer is full, it rejects additional data from the sending process, controlling the rate of data sent.

Flow control

Opening and Closing Windows

Window adjustments:

• The window closes as data is sent or received.
• The window opens when acknowledgments are received (send window) or data is processed by the receiver (receive window).

Flow control

A Scenario

• During the connection setup, the send and receive windows are set. Their sizes change as data is transferred. Figure 24.20 shows a simple one-way data transfer from the client to the server.
• For now, we assume there are no errors—no segments are lost, damaged, duplicated, or received out of order.
• Only two windows are shown because data flows in one direction. Even though the client defines the server’s window size as 2000 in the third segment, it isn’t shown since communication happens only one way.

Flow control

A Scenario

​

​

Two windows – one way communication from the client to the server.

• Send window – shows how much data the sender (client) can send before needing an acknowledgment.
• Receive window – shows how much data the receiver (server) can accept (its buffer space).

If communication is two-way (both client and server send and receive data), then there are four windows in total:

• Client’s send window
• Client’s receive window
• Server’s send window
• Server’s receive window

In the handshake method , each side shares its receive window size, not its send window size.

Flow control

Flow control

Connection Initiation (Three-Way Handshake):

​

• Segment 1: The client starts the connection by sending a SYN with a sequence number (seqNo) of 100. The server sets up resources for the connection, such as a receive buffer of 800 bytes (rwnd = 800 → the server can receive up to 800 bytes of data).

​

• Segment 2: The server replies with a SYN + ACK, acknowledging the client's sequence number (expected seqNo = 101). It also advertises its receive window of 800 bytes.

​

• Segment 3: The client completes the handshake with an ACK (ackNo = 101) and increases its advertised receive window size to 2000 bytes.

Flow control

Data Transfer:

​

• Segment 4: The client sends 200 bytes of data starting at seqNo = 101. Its send window adjusts to reflect the in-transit bytes.

​

• Segment 5: The server acknowledges the 200 bytes (ackNo = 301). Its receive window (rwnd) decreases to 600 bytes since 200 bytes are now buffered.

​

• Segment 6: The client sends 300 bytes starting from seqNo = 301. The server’s receive window decreases further to 400 bytes as only 100 bytes of data have been consumed so far.

Flow control

Data Transfer:

• Segment 7: The server acknowledges the 300 bytes (ackNo = 601) and advertises an updated receive window of 400 bytes.

​

• Segment 8: The server processes some data and increases its receive window to 600 bytes. It informs the client, signaling readiness to accept more data.

Flow control Mechanism

• The send and receive windows in TCP adjust dynamically based on data flow and acknowledgments:
• Send Window:
1. Shrinks as data is sent but not acknowledged(available space in the window decreases).
2. Expands when the receiver acknowledges received data.
3. The sender avoids shrinking the window (moving the right edge left) to prevent issues like sending data outside the valid range.
• Receive Window (rwnd):
• Reflects the available buffer space at the receiver.
• Internally, the buffer space decreases (or appears to "shrink") when data is received but not yet processed by the receiving application.
• Expands when the data is consumed by the receiving process.

​

Flow control Mechanism

Shrinking Behavior:

• The receive window cannot shrink, but the send window may shrink if the receiver advertises a smaller rwnd value.

​

Relationship Rule:

• To prevent errors, the new send window size must always be greater than or equal to the previous size.
• This ensures no data falls outside the allowed range.

Flow control Mechanism

Flow control Mechanism

• Window Shutdown: If the receiver is temporarily unable to process more data (for example, when it runs out of buffer space), it can send a rwnd of 0 to the sender. This doesn’t shrink the window but tells the sender to stop sending data.

​

• The sender will wait until the receiver updates the window size. However, to prevent a deadlock (where the sender and receiver are stuck), the sender can still send a single byte as a "probe" to check if the window has reopened.

Flow control

Silly Window Syndrome (SWS)

​

• The Silly Window Syndrome (SWS) is a phenomenon in TCP transmission where data is sent in inefficiently small segments, leading to poor utilization of network resources.
• This typically occurs when either the sending or receiving application creates or consumes data too slowly.

​

• The resulting small segments, particularly in cases where the data is only 1 byte at a time, cause overhead in the form of multiple headers (e.g., TCP/IP headers) for each small segment, which reduces the effective data transfer rate.

​

Flow control

SWS Caused by the Sender

• Sometimes, the sender causes a problem by sending data very slowly, for example, 1 byte at a time. This happens when the sending application writes tiny amounts of data to the TCP buffer.
• If the sender sends these tiny segments without control, each segment still has TCP/IP headers, which makes the network inefficient.
• Solution: Nagle’s Algorithm – it helps the sender combine small pieces of data into larger segments before sending, reducing overhead and using the network efficiently.

Flow control

• Solution: Nagle’s Algorithm

​

• Send the first byte immediately.
• After that, the sender holds new data until:
• It receives an acknowledgment from the receiver, or
• Enough data is collected to fill a full TCP segment (Maximum Segment Size, MSS).
• Repeat this process for all subsequent data.

​

Benefit:

• Prevents sending lots of tiny segments.
• Balances the speed of the application with the network’s capacity.

​

Flow control

SWS Caused by the Receiver

• The receiver can also cause the silly window syndrome if it consumes data very slowly, such as processing 1 byte at a time.
• For example, the sender may send a large block of data (e.g., 1 KB), but the receiver only consumes 1 byte at a time.
• As the receiver fills its buffer, it may advertise a small window size (e.g., 1 byte), causing the sender to send data in very small chunks. This leads to inefficiency similar to the sender-induced problem.

Flow control

Clark's Solution:

• Sometimes, the receiver immediately acknowledges data but sets its window size to zero.
• The receiver only increases the window when there is enough space for a full segment (or at least half the buffer).
• This prevents the sender from sending small, inefficient segments.

Delayed Acknowledgment:

• If a small segment arrives, the receiver doesn’t immediately send an ACK.
• It waits until more data arrives and the buffer has enough space for a full-sized segment.
• This prevents the sender from sending many tiny, inefficient segments.

​

Error control

TCP (Transmission Control Protocol) is a reliable transport-layer protocol designed to ensure data is delivered correctly and in order from the sender to the receiver.

It achieves reliability through error control mechanisms, which include

1. Checksum,

2. Acknowledgment, and

3. Retransmission strategies.

Error control

Checksum:

• Each TCP segment contains a 16-bit checksum field.
• The checksum is used to verify data integrity, ensuring that no corruption occurs during transmission.
• If the checksum does not match the received data, the segment is discarded by the receiver and considered lost. The receiver then requests the segment to be retransmitted.

Error control

Acknowledgment (ACK):

• Acknowledgments are used by TCP to confirm the successful receipt of data.
• Acknowledgments can be cumulative (the receiver indicates the next byte expected) or selective (SACK), which allows the receiver to acknowledge specific blocks of data, including out-of-order or duplicated segments.

Error control

Types of Acknowledgments:

• Cumulative Acknowledgment: The receiver sends back an acknowledgment with the sequence number of the next expected byte. This method does not provide feedback for lost or out-of-order segments.
• Selective Acknowledgment (SACK): Introduced to improve TCP reliability, SACK allows the receiver to inform the sender about blocks of data that were received out-of-order or duplicated. This is added as an option in the TCP header since there is no space in the fixed header fields for such information.

Error control

Generating Acknowledgments:

• A receiver follows specific rules to decide when to send an acknowledgment:
• Piggybacking: When the receiver sends data, it includes an acknowledgment indicating the next expected byte, reducing the number of separate ACK segments.
• Delayed ACKs: If no data needs to be sent and the receiver has already acknowledged the previous segment, it delays the acknowledgment until another segment arrives or a timeout occurs (typically 500 ms). This reduces the number of ACKs.
• Immediate ACKs: If a segment arrives and the previous one has not been acknowledged, the receiver immediately sends an ACK for the expected byte.

Error control

Generating Acknowledgments:

• A receiver follows specific rules to decide when to send an acknowledgment:
• Out-of-order ACKs: If a segment arrives out of order, the receiver immediately acknowledges the next expected byte. This helps trigger fast retransmission of the missing segments.
• ACK for missing segments: When a missing segment arrives, the receiver sends an acknowledgment for the next expected byte.
• Duplicate segments: If a duplicate segment arrives, the receiver discards it but sends an ACK for the next expected byte.

Error control

Retransmission in TCP

• Retransmission is crucial for ensuring reliable delivery of data in TCP. It is used when segments are lost, corrupted, or not acknowledged within a certain time frame. Here's an explanation of the retransmission process:
• Retransmission after RTO (Retransmission Timeout):
1. TCP maintains a retransmission timer (RTO) for each connection. If a segment is not acknowledged within the specified time, it is retransmitted.
2. When the timer expires, TCP retransmits the segment with the smallest sequence number in the queue and resets the timer.
3. The value of RTO is dynamic and is adjusted based on the Round-Trip Time (RTT), which measures the time for a segment to reach its destination and for an acknowledgment to return.

Error control

Retransmission after Three Duplicate ACKs (Fast Retransmission):

• If three duplicate ACKs (i.e., the same acknowledgment repeated three times) are received for the same segment, TCP performs a fast retransmission without waiting for the RTO to expire. This method accelerates the process by retransmitting the missing segment immediately, assuming that the segment has been lost and not corrupted.

Out-of-Order Segments:

• TCP implementations do not discard out-of-order segments. Instead, they store them temporarily and flag them as out of order. The out-of-order segments are not delivered to the application until the missing segments arrive. This ensures that data is delivered in the correct sequence to the receiving application.

Finite State Machines (FSMs) for TCP Data Transfer

• TCP's operation can be modeled using Finite State Machines (FSMs), which outline how the sender and receiver handle data transfer, acknowledgments, retransmissions, and other processes. FSMs for both the sender and receiver:

Sender-Side FSM

• Data Arrival and Segment Creation: When data arrives from the application, the sender creates a TCP segment, stores a copy in the queue, and sends it.
• If this is the first segment in the queue, the retransmission timer is started(to keep track of how long the sender should wait for an acknowledgment (ACK) before assuming the packet was lost).

Finite State Machines (FSMs) for TCP Data Transfer

Finite State Machines (FSMs) for TCP Data Transfer

Sender-Side FSM

• Retransmission on Timeout: If the retransmission timer expires before the segment is acknowledged, the sender retransmits the segment in the front of the queue and restarts the timer.

​

• Retransmission on Duplicate ACKs: If three duplicate ACKs are received for a segment (indicating that the segment is missing), the sender performs fast retransmission and resets the duplicate acknowledgment counter.

Finite State Machines (FSMs) for TCP Data Transfer

Sender-Side FSM

​

​

​

Retransmitted Segment 3 arrives

• The receiver now finally has segments 1 → 5 all in order.
• So, it can deliver them to the application layer.
• It sends ACK 6, because it has received everything up to segment 5.

​

• Sliding the Window: Once an acknowledgment is received for a segment, the sender slides the window and adjusts the window size based on the receiver’s advertised window (rwnd). The segment is then removed from the queue.

Finite State Machines (FSMs) for TCP Data Transfer

Receiver-Side

• Receiving and Acknowledging Segments: The receiver stores incoming segments, even if they are out of order, until the missing segments arrive. It acknowledges the received segments by sending ACKs back to the sender.
• Handling Out-of-Order Segments: If segments arrive out of order, the receiver stores them temporarily and does not deliver them to the application until the missing segments are received and processed.
• Sliding the Window: The receiver adjusts its advertised window (rwnd) based on available buffer space and the flow control mechanism.

Finite State Machines (FSMs) for TCP Data Transfer

Some Scenarios

1. Normal Operation: In this scenario, bidirectional data transfer occurs between the client and server, where the server sends three segments after receiving one from the client. The acknowledgment rules are as follows:

​

• Sender (Client): The client starts by sending the first segment of data.
• Receiver (Server): The server acknowledges the segment by informing the client about the next byte it expects (Rule 1).
• Client (Delayed ACK): If the client has no new data to send, it waits (500 ms) before sending an acknowledgment (Rule 2).
• Immediate ACK (Client): If the client receives more data (third segment) from the server during this delay, it immediately sends an acknowledgment (Rule 3).

Some Scenarios

Normal Operation:

​

Some Scenarios

Normal Operation:

​

Rule 1 — Normal ACK after receiving data

• The client sends data (Seq: 1201–1400) to the server.
• The server replies with ACK 1401,�“I have received up to byte 1400; send me 1401 next.”
• Similarly, the server also sends data (Seq: 4001–5000) to the client, and the client sends ACK 4001 back.

Rule 2 — Delayed ACK (500 ms waiting time)

• Now the server sends another segment (Seq: 4001–5000).
• The client receives it but does not send an ACK immediately it starts an ACK-delaying timer (500 ms), it can acknowledge multiple segments together,
• The client waits - if no more data arrives during this delay, after 500 ms, it finally sends ACK 5001.

Rule 3 — Immediate ACK when new data arrives before timeout

• The server now sends another segment (Seq: 5001–6000), and soon after that, another one (Seq: 6001–7000) both before the 500 ms delay finishes.
• The client sees that new data arrived before the timer expired, so, it immediately sends an ACK (ACK 7001) without waiting. This is Rule 3: Immediate ACK.

Some Scenarios

2. Lost Segment (Figure 24.25):

The sender transmits segments 1 and 2, which are acknowledged immediately. However, segment 3 is lost (possibly discarded by a router).

The receiver then receives segment 4, which is out of order. It stores segment 4 but acknowledges the missing segment by sending an acknowledgment indicating the next expected byte (rule 4).

The sender's retransmission timer expires, and it retransmits segment 3, which is then acknowledged by the receiver (rule 5).

​

Some Scenarios

Lost Segment (Figure 24.25):

​

Some Scenarios

3. Fast Retransmission (Figure 24.26):

​

• In this case, instead of waiting for the RTO to expire, the sender receives three duplicate acknowledgments for the same segment, indicating that segment 3 is missing.

​

• The sender immediately retransmits segment 3 upon receiving these duplicate ACKs, without waiting for the RTO timer to expire. This process, called fast retransmission, speeds up recovery from lost segments.

Some Scenarios

• Fast Retransmission (Figure 24.26):

Some Scenarios

• Delayed Segment: TCP segments may experience different delays due to varying routes in the network. If a segment is delayed and the sender assumes it’s lost (and retransmits it), the delayed segment may still arrive after the retransmission. When this happens, the original segment which comes later is treated as a duplicate segment and discarded by the receiver.

​

• Duplicate Segment: If a duplicate segment arrives, it has the same sequence number as a previously received segment. The destination TCP simply discards the duplicate segment and sends an acknowledgment (ACK) indicating the next expected sequence number. This prevents delivering out-of-order data and ensures continuous, in-order delivery to the application.

Some Scenarios

• Automatically Corrected Lost ACK: If an ACK is lost, TCP still works reliably because it uses cumulative acknowledgments. This means the next ACK confirms all data sent so far, including the part whose ACK was lost. The sender doesn’t need to know about the missing ACK.

​

• Lost Acknowledgment Corrected by Resending a Segment: If an ACK is lost or delayed, TCP retransmits the segment after the timeout. The receiver ignores duplicate data and sends the latest ACK, confirming all received data.

Some Scenarios

Deadlock

• Suppose the ACK that tells the sender “you can send more data” is lost.
• The sender waits because it thinks the receiver is full.
• The receiver waits, thinking the sender has no data left.
• Result: both are waiting forever → this is a deadlock.

​

Solution (Persistence Timer):

• TCP uses a persistence timer.
• If the sender waits too long without receiving an updated window, the timer forces it to ask again or retransmit the lost ACK.
• This breaks the deadlock and data transfer continues.

TCP Congestion Control

• TCP uses different policies to handle the congestion in the network.

​

Send Window Control

• Controlled by the receiver using rwnd (advertised in segments).
• Ensures the receiver's buffer doesn't overflow (prevents end congestion).

Intermediate Buffer Congestion

• Routers may become overwhelmed despite large buffers.
• Congestion in the network can cause dropped segments, affecting error control.

Impact of Congestion

• Lost segments lead to retransmissions, worsening congestion and risking communication collapse.

TCP Congestion Control

• TCP uses different policies to handle the congestion in the network.

​

TCP's Responsibility

• TCP has to manage congestion itself because IP does not control network congestion.

Balanced Approach

• TCP balances sending speed: it avoids sending too fast to prevent congestion and avoids sending too slow to make full use of the network bandwidth

TCP Congestion Control

• TCP uses different policies to handle the congestion in the network.

​

​

Congestion Window (cwnd): Send Window Size=min(cwnd, rwnd)= min(8,5)= 5

• Congestion Window (cwnd): Set by TCP to avoid overloading the network.
• Receiver Window (rwnd): Set by the receiver to show how much buffer space is free.�The sender uses the smaller of cwnd and rwnd as the Send Window Size.

​

Eg: Suppose the network can safely handle 8 KB of data (congestion window, cwnd = 8 KB).

The receiver has only 5 KB free in its buffer (receiver window, rwnd = 5 KB).

The sender can only send 5 KB at this time, because TCP takes the smaller of cwnd and rwnd.

This prevents network congestion and receiver buffer overflow.

Congestion Detection in TCP

• Signs of Congestion�TCP identifies congestion through two primary events:
1. Timeout:
1. If no ACK is received before the timeout, TCP assumes segment loss due to severe congestion.
2. Three Duplicate ACKs:
• Receiving three duplicate ACKs (four ACKs with the same acknowledgment number) indicates a missing segment.
• This is mild congestion, as subsequent segments are still being received.

Congestion Detection in TCP

​

• Congestion Feedback Mechanism
• TCP relies solely on acknowledgment (ACK) feedback from the receiver.
• Timeout: Lack of ACKs implies strong congestion.
• Duplicate ACKs: Regular ACKs with repeated acknowledgment numbers imply mild congestion.
• TCP Versions
• Tahoe TCP: Treats both events identically, restarting the congestion control process with slow start.
• Reno TCP: Differentiates between the two, handling timeouts and duplicate ACKs with distinct strategies.

​

Congestion Policies in TCP

​

TCP uses three main algorithms to handle congestion effectively:

slow start

congestion avoidance

fast recovery.

​

These algorithms adjust the size of the congestion window (cwnd) to ensure efficient data transmission without overwhelming the network.

Congestion Policies in TCP

Slow Start:

The sender begins with a congestion window (cwnd) size of 1 MSS (Maximum Segment Size).

• This phase is aggressive, as cwnd grows exponentially—doubling every RTT.
• Each acknowledgment (ACK) increases cwnd by 1 MSS.
• The growth continues until the slow-start threshold (ssthresh) is reached.
• If a time-out or 3 duplicate ACKs are detected during this phase, TCP resets cwnd to 1 MSS and halves ssthresh, restarting the slow start phase.

If an ACK arrives, cwnd = cwnd + 1

Congestion Policies in TCP

Congestion Avoidance

​

• When It Starts: This phase begins after the Slow Start phase, once the congestion window (cwnd) reaches a certain threshold (ssthresh).

​

• Slower Growth: Instead of doubling the window size like in Slow Start, cwnd grows slowly and steadily. For every round-trip time (RTT), cwnd increases by 1 MSS (Maximum Segment Size), making the growth linear.

If an ACK arrives, cwnd = cwnd + 1

Congestion Policies in TCP

Slow Start:

• Suppose ssthresh = 16 MSS.
• In Slow Start, cwnd grows: 1 → 2 → 4 → 8 → 16 MSS (doubling each RTT).
• When cwnd hits 16 MSS, it has reached ssthresh, and TCP switches to Congestion Avoidance, growing cwnd linearly instead of exponentially.

TCP assumes it’s close to the network’s limit - so it stops doubling and switches to Congestion Avoidance to prevent packet loss.

Congestion Avoidance

• Once cwnd reaches ssthresh (e.g., 16 MSS in your example), TCP stops doubling cwnd.
• In Slow Start: cwnd doubles every RTT, After reaching ssthresh TCP enters Congestion Avoidance, where cwnd grows slowly and linearly—by 1 MSS per RTT, not doubling.
• This prevents TCP from sending too much data too fast, which could cause network congestion.

Congestion Policies in TCP

• Fast Recovery: After 3 duplicate ACKs, TCP halves cwnd to reduce congestion risk.

​

When 3 duplicate ACKs arrive:

• TCP assumes one segment is lost, not all.
• It retransmits that missing segment immediately (fast retransmit).
• Then, it does not drop cwnd to 1 MSS — instead, it “inflates” it a bit
• . For each additional duplicate ACK, cwnd grows slightly by 1/cwnd.
• The fast-recovery algorithm is optional in TCP. The old version of TCP did not use it, but the new versions try to use it.

TCP- Policy Transition

Taho TCP:

It is one of the earliest versions of Transmission Control Protocol (TCP) and focuses on reliable data delivery through simple congestion control mechanisms. It employs two main algorithms: Slow Start and Congestion Avoidance, ensuring efficient utilization of network resources while minimizing congestion.

​

• Slow Start: Begins with a small congestion window (cwnd) of 1 MSS.

Exponential Growth: Doubles cwnd every RTT until reaching ssthresh or congestion

​

• Congestion Avoidance: Activates when cwnd reaches ssthresh.

Linear Growth: Size of cwnd changed to 1 MSS per RTT to avoid congestion.

TCP- Policy Transition

Taho TCP:

• Congestion Detection: Detects congestion via timeouts or three duplicate ACKs.

On detection:

• Resets cwnd to 1 MSS.
• Updates ssthresh to half of the current cwnd.

​

• Dynamic Threshold Adjustment: Adjusts ssthresh with each congestion event, improving network adaptation.

​

TCP- Policy Transition

Taho TCP:

TCP- Policy Transition

Reno TCP

Reno TCP is an improved version of Taho TCP that introduces a new state called Fast Recovery, enabling more efficient handling of duplicate ACKs and distinguishing between minor and severe congestion events.

Time-out Handling: Severe congestion is indicated by a time-out.

TCP resets the cwnd to 1 MSS and moves to the Slow Start state.

TCP- Policy Transition

Reno TCP

Fast Recovery State: When the sender gets three duplicate ACKs, it means one packet got lost, but the connection is still working.

So, instead of going back to the beginning (like in Slow Start), the sender slightly increases its window to (cwnd) is increased to ssthresh + 3 MSS.

​

• As the sender keeps getting duplicate ACKs, it continues to increase the cwnd quickly (exponentially).

TCP- Policy Transition

Reno TCP

• TCP leaves Fast Recovery in two cases:

​

• If a time-out happens → It means the network is badly congested.�So, TCP restarts using Slow Start (cwnd = 1 MSS).
• If a new ACK (not duplicate) arrives → It means the lost packet has been received successfully.

​

• TCP then reduces cwnd back to ssthresh and switches to Congestion Avoidance (slow, linear growth).

​

TCP- Policy Transition

Reno TCP

TCP- Policy Transition

New Reno TCP

NewReno TCP improves Reno by handling multiple lost segments in the same window more efficiently. It enhances Fast Recovery to process partial ACKs and avoid repeated duplicate ACKs.

Handling Multiple Segment Losses:

• Upon receiving three duplicate ACKs, TCP retransmits the first lost segment immediately.
• After retransmitting, TCP waits for a new ACK (not a duplicate).
• If the new ACK acknowledges all data up to the end of the congestion window, only one segment was lost.
• If the new ACK acknowledges a partway in the window, additional segments are likely lost, and TCP retransmits the next lost segment.

TCP- Policy Transition

New Reno TCP

Improved Fast Recovery: Stays in the Fast Recovery state until all segments from the congestion window are acknowledged.

​

• This avoids frequent time-outs or unnecessary resets to Slow Start, making recovery smoother and faster.

TCP- Policy Transition

TCP Throughput

• TCP throughput depends on the congestion window (cwnd) and Round-Trip Time (RTT).
• Assuming steady cwnd, throughput is:

• In reality, cwnd fluctuates in a sawtooth pattern between a maximum (Wmax) and half of it.
• Average throughput:

• Actual rate of successful data transmission over a network

TCP- Policy Transition

TCP Throughput

TCP- Policy Transition

TCP Throughput

• Eg: MSS = 10 KB, RTT = 100 ms, and average Wmax = 9.6 MSS.

When considering Maximum Segment Size (MSS) in the TCP throughput formula, it accounts for the actual size of the data packets sent: