Flow Control, Stop-and-Wait ARQ, and Its Disadvantages

1. Flow Control

Flow control is a mechanism used at the Data Link Layer (and also at the Transport Layer) to regulate the rate of data transmission between a sender and a receiver so that the receiver is not overwhelmed by data faster than it can process.

: "The data rate must be constant on both sides else the data may get corrupted."

Without flow control:

• A fast sender can flood a slow receiver's buffer.
• Buffer overflow leads to data loss and corruption.

Flow control ensures that the sender transmits data only at a rate the receiver can handle, maintaining reliable and orderly communication.

2. Stop-and-Wait ARQ Protocol

ARQ stands for Automatic Repeat reQuest. It is an error control mechanism that uses acknowledgements (ACK) and retransmissions to ensure reliable delivery of frames.

Stop-and-Wait ARQ is the simplest form of ARQ. The working principle is:

The sender sends one frame at a time and then stops and waits for an acknowledgement (ACK) from the receiver before sending the next frame.

How Stop-and-Wait ARQ Handles Errors

There are three main error scenarios handled by this protocol:

Case 1: Frame Arrives Correctly (No Error)

Sender                        Receiver
  |------- Frame 0 ----------->|
  |<------- ACK 1 -------------|
  |------- Frame 1 ----------->|
  |<------- ACK 0 -------------|

• Sender sends Frame 0.
• Receiver receives it correctly and sends ACK 1 (ready for frame 1).
• Sender sends the next frame upon receiving ACK.

Case 2: Frame is Lost or Damaged (Frame Error)

Sender                        Receiver
  |------- Frame 0 ---X        |   (frame lost/damaged)
  |   (Timer expires)          |
  |------- Frame 0 ----------->|   (retransmit)
  |<------- ACK 1 -------------|

• The sender starts a timer after sending each frame.
• If the frame is lost or corrupted, the receiver does not send an ACK.
• When the timer expires, the sender retransmits the same frame.
• This continues until a correct ACK is received.

Case 3: ACK is Lost or Damaged (ACK Error)

Sender                        Receiver
  |------- Frame 0 ----------->|
  |        ACK 1 ---X          |   (ACK lost)
  |   (Timer expires)          |
  |------- Frame 0 ----------->|   (retransmit)
  |<------- ACK 1 -------------|

• The receiver correctly receives Frame 0 and sends ACK 1, but the ACK is lost.
• The sender's timer expires and it retransmits Frame 0.
• The receiver gets a duplicate frame (Frame 0 again).
• The receiver discards the duplicate (because it already received Frame 0) and resends ACK 1.
• Sequence numbers (0 and 1) are used to detect duplicates.

Case 4: ACK is Delayed (Late ACK)

• If an ACK arrives after the timer has expired and the sender has already retransmitted:
  • The sender receives a delayed ACK.
  • It ignores the delayed ACK because it has already retransmitted and is waiting for a fresh ACK.
  • Sequence numbers help distinguish old ACKs from new ones.

Summary of Error Handling Mechanisms

3. Disadvantages of Stop-and-Wait ARQ

1. Very Low Efficiency / Poor Throughput

• The sender sends only one frame at a time and then sits idle waiting for an ACK.
• If propagation delay is large (e.g., satellite links), the channel is wasted for most of the time.
• Efficiency = 1 / (1 + 2a) where a = propagation delay / transmission time
• For large values of a, efficiency drops drastically.

2. Slow Data Transfer

• Because only one frame is in transit at any time, the overall data transfer rate is very slow compared to the available bandwidth.

3. Wastes Bandwidth

• The communication channel remains idle while the sender waits for an ACK, leading to severe underutilization of the available bandwidth.

4. Not Suitable for Long-Distance Communication

• On links with high propagation delay (e.g., satellite or intercontinental links), the round-trip time is very large, making Stop-and-Wait extremely inefficient.

5. Performance Degrades with Errors

• Every time an error occurs, the sender must wait for the timer to expire before retransmitting, adding significant delay.

6. Only One Frame Buffered

• The sender needs to keep only one frame in its buffer, but this severely limits the pipeline and throughput.

Conclusion

Stop-and-Wait ARQ is a simple and easy-to-implement error control protocol that handles frame loss, frame damage, ACK loss, and duplicate frames using timers, retransmissions, and sequence numbers. However, its one-frame-at-a-time approach makes it highly inefficient, especially over high-latency or high-bandwidth links. More advanced protocols like Go-Back-N ARQ and Selective Repeat ARQ were developed to overcome these limitations by allowing multiple frames to be in transit simultaneously (pipelining).

TCP Header - Explanation with Diagram

Introduction

TCP (Transmission Control Protocol) is a connection-oriented, reliable transport layer protocol. It ensures that data is delivered accurately and in order between two communicating hosts. The TCP header contains all the control information necessary to manage this reliable communication.

TCP Header Diagram

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data  |Reserv.|U|A|P|R|S|F|                                   |
|Offset |  (6)  |R|C|S|S|Y|I|         Window Size              |
|  (4)  |       |G|K|H|T|N|N|                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options (if any)           |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Data                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Minimum TCP Header Size = 20 bytes (without options)

Detailed Explanation of Each Field

1. Source Port (16 bits)

• Identifies the port number of the sending application on the source host.
• Port numbers range from 0 to 65535.
• Example: A web browser may use port 1025 as source port.

Use: Helps the receiving host know which application sent the data, enabling proper reply routing.

2. Destination Port (16 bits)

• Identifies the port number of the receiving application on the destination host.
• Example: HTTP uses port 80, HTTPS uses port 443, FTP uses port 21.

Use: Directs the incoming segment to the correct application/process on the destination machine.

3. Sequence Number (32 bits)

• Indicates the position (byte number) of the first byte of data in this segment within the overall data stream.
• During connection establishment (SYN), it carries the Initial Sequence Number (ISN).

Use: Enables the receiver to reorder segments that arrive out of order and detect missing data.

4. Acknowledgment Number (32 bits)

• When the ACK flag is set, this field contains the next sequence number the sender of the acknowledgment expects to receive.
• It acknowledges all bytes received up to (but not including) this number.

Use: Provides reliable delivery by confirming receipt of data and requesting the next expected byte.

5. Data Offset / Header Length (4 bits)

• Specifies the length of the TCP header in 32-bit words.
• Minimum value is 5 (20 bytes), maximum is 15 (60 bytes).

Use: Tells the receiver where the actual data begins in the TCP segment.

6. Reserved (6 bits)

• These bits are reserved for future use and must be set to zero.

7. Control Flags (6 bits)

Each flag is 1 bit and serves a specific control purpose:

Use: These flags control the state of the TCP connection - establishment, data transfer, and termination.

8. Window Size (16 bits)

• Specifies the number of bytes the sender is willing to accept from the receiver (receive buffer size).
• Maximum window size = 65,535 bytes (can be scaled using options).

Use: Implements flow control - prevents the sender from overwhelming the receiver by sending too much data at once.

9. Checksum (16 bits)

• A 16-bit error-detection field computed over the TCP header, data, and a pseudo-header (containing source IP, destination IP, protocol, and TCP length).

Use: Ensures data integrity - detects any corruption that may have occurred during transmission.

10. Urgent Pointer (16 bits)

• Valid only when the URG flag is set.
• Points to the last byte of urgent data within the segment.

Use: Allows TCP to send out-of-band (priority) data that should be processed immediately by the receiving application.

11. Options (Variable, 0 to 40 bytes)

• Used for optional parameters that are negotiated when the connection is set up, such as the maximum segment size, the window scale factor, selective acknowledgment permission, and timestamps.
• Present only when the data offset is greater than 5, which is why the header can grow from 20 bytes up to 60 bytes.

Use: Lets TCP extend its behaviour beyond the fixed 20-byte header, for example by agreeing on a larger window or a segment size that avoids fragmentation.

12. Padding (Variable)

• Extra zero bits added after the options so that the header ends on a 32-bit word boundary.

Use: Keeps the header length an exact multiple of 4 bytes, so the value carried in the data offset field remains valid.

Uses of the TCP Header

Conclusion

Every field of the TCP header exists to support one of the guarantees TCP makes. The port numbers deliver the segment to the right process, the sequence and acknowledgment numbers together with the checksum make the delivery reliable and in order, the flags manage the life of the connection, and the window size keeps a fast sender from overwhelming a slow receiver. This is why the minimum header is 20 bytes and can grow to 60 bytes when options are negotiated.

Port vs Socket and Leaky Bucket Algorithm

Part 1: Difference Between Port and Socket

A socket is one endpoint of a two-way communication link between two programs running on the network.

Part 2: Leaky Bucket Algorithm

Definition

The Leaky Bucket Algorithm is used to control the rate of data transmission in a network. It is implemented as a single server queue with constant service time. The key idea is:

• Input rate can vary (bursty traffic)
• Output rate remains constant
• If the bucket (buffer) overflows, packets are discarded

It converts bursty traffic into fixed-rate (smooth) traffic by averaging the data rate.

How It Works

Incoming packets (variable rate)
        |
        v
   [ BUCKET / BUFFER ]
        |
        v
Outgoing packets (constant rate)

1. Packets arrive at irregular/bursty intervals and enter the bucket (queue).
2. The bucket leaks (outputs) packets at a fixed constant rate.
3. If the bucket is full, any new incoming packet is dropped/discarded.
4. This ensures the network receives a smooth, uniform flow of data.

Example

Suppose:

• Bucket size (buffer capacity) = 10 packets
• Output rate = 2 packets per second

• At time 3: 7 (existing) + 8 (arriving) = 15, but bucket size is only 10, so 3 packets are dropped.
• Output is always a constant 2 packets/sec, regardless of how many arrive.

Advantages

• Prevents network congestion by smoothing out bursty traffic.
• Ensures a constant output rate for downstream devices.

Disadvantage

• Bursty traffic that exceeds bucket size leads to packet loss.