TCP Flow Control - Sliding Window & Congestion Control (AIMD)

▶

Steps

setup

Initialize Sender and Receiver

The sender initializes its congestion window (cwnd) to 1 and slow start threshold (ssthresh) to 8. The receiver is ready to accept packets starting at sequence number 1.

💡 Setting initial cwnd and ssthresh is crucial to start TCP's congestion control and flow control mechanisms.

Line:

cwnd = 1
ssthresh = 8
next_seq_num = 1
ack_expected = 1

💡 TCP starts cautiously with a small congestion window to probe network capacity.

fill_cells

Send First Packet (seq=1)

Sender sends the first data packet with sequence number 1, starting the sliding window transmission.

💡 Sending the first packet triggers the start of data flow and window tracking.

Line:

send_packet(seq_num=1)

💡 The sliding window begins with the first packet; only one packet is sent due to cwnd=1.

traverse

Packet seq=1 Arrives at Receiver

The packet with sequence number 1 arrives at the receiver, which processes it and prepares an acknowledgment.

💡 Receiver must confirm receipt to allow the sender to advance its window.

Line:

receive_packet(seq_num=1)
send_ack(ack_num=2)

💡 Acknowledgments enable the sender to know which packets were received successfully.

fill_cells

Send ACK for seq=2

Receiver sends an acknowledgment packet indicating it expects sequence number 2 next.

💡 ACKs inform the sender that the previous packet was received successfully.

Line:

send_ack(ack_num=2)

💡 ACK number indicates the next expected sequence number, advancing the sliding window.

traverse

ACK for seq=2 Arrives at Sender

The sender receives the ACK for sequence number 2, confirming packet 1 was received and allowing window advancement.

💡 Receiving ACKs lets the sender slide its window and send more packets.

Line:

receive_ack(ack_num=2)
cwnd = cwnd + 1  # additive increase

💡 Additive increase grows the congestion window linearly to probe for available bandwidth.

fill_cells

Send Packets seq=2 and seq=3

With cwnd now 2, sender transmits packets with sequence numbers 2 and 3 to fill the window.

💡 Sending multiple packets in flight improves throughput while respecting congestion control.

Line:

send_packet(seq_num=2)
send_packet(seq_num=3)

💡 The sliding window allows multiple packets to be sent before waiting for ACKs.

traverse

Packet seq=2 Arrives at Receiver

Packet with sequence number 2 arrives at the receiver and is processed.

💡 Receiver processes packets in order to maintain reliable delivery.

Line:

receive_packet(seq_num=2)
send_ack(ack_num=4)

💡 Receiver acknowledges the highest contiguous sequence number received.

fill_cells

Send ACK for seq=4

Receiver sends an ACK indicating it expects sequence number 4 next, acknowledging packets 2 and 3.

💡 ACKs cumulatively acknowledge all packets up to but not including the ack number.

Line:

send_ack(ack_num=4)

💡 Cumulative ACKs reduce overhead and confirm multiple packets received.

traverse

ACK for seq=4 Arrives at Sender

Sender receives ACK=4, confirming packets 2 and 3 were received. Sender increases cwnd by 1 (additive increase).

💡 Successful ACKs allow the sender to increase its congestion window and send more data.

Line:

receive_ack(ack_num=4)
cwnd = cwnd + 1

💡 Additive increase grows cwnd linearly to probe network capacity safely.

fill_cells

Send Packets seq=4, seq=5, seq=6

With cwnd=3, sender sends packets 4, 5, and 6 to fill the congestion window.

💡 Increasing cwnd allows more packets to be sent before waiting for ACKs, improving throughput.

Line:

send_packet(seq_num=4)
send_packet(seq_num=5)
send_packet(seq_num=6)

💡 Sliding window and congestion window together control the number of packets in flight.

traverse

Packet seq=4 Arrives at Receiver

Packet 4 arrives at the receiver and is processed, preparing an ACK for the next expected sequence number.

💡 Receiver confirms receipt to maintain reliable delivery and flow control.

Line:

receive_packet(seq_num=4)
send_ack(ack_num=7)

💡 Receiver acknowledges all packets up to seq=6 cumulatively.

fill_cells

Send ACK for seq=7

Receiver sends an ACK indicating it expects sequence number 7 next, cumulatively acknowledging packets 4, 5, and 6.

💡 This cumulative ACK confirms receipt of multiple packets, allowing the sender to advance its window.

Line:

send_ack(ack_num=7)

💡 Cumulative ACKs efficiently confirm multiple packets, reducing overhead.

traverse

ACK for seq=7 Arrives at Sender

Sender receives ACK=7, confirming packets 4, 5, and 6 were received. Sender increases cwnd from 3 to 4 (additive increase).

💡 Each successful ACK allows the sender to increase cwnd and send more packets.

Line:

receive_ack(ack_num=7)
cwnd = cwnd + 1

💡 Additive increase continues to probe network capacity safely.

fill_cells

Send Packet seq=7

Sender sends packet with sequence number 7, filling the congestion window of size 4.

💡 Sending packets up to cwnd size maximizes throughput while avoiding congestion.

Line:

send_packet(seq_num=7)

💡 Sliding window and congestion window together regulate packet flow.

traverse

Packet seq=7 Arrives at Receiver

Packet 7 arrives at the receiver and is processed, which completes the current data transfer window.

💡 Receiver confirms receipt to maintain reliable delivery and flow control.

Line:

receive_packet(seq_num=7)
send_ack(ack_num=8)

💡 Receiver acknowledges the next expected sequence number after the last received packet.

fill_cells

Send Final ACK for seq=8

Receiver sends the final ACK indicating it expects sequence number 8 next, confirming all sent packets were received.

💡 Final ACK confirms successful delivery of all packets in this window.

Line:

send_ack(ack_num=8)

💡 Final ACK signals completion of this transmission phase.

traverse

Final ACK for seq=8 Arrives at Sender

Sender receives the final ACK=8, confirming all packets sent were acknowledged. Congestion window is increased to 5.

💡 Final ACK confirms successful transmission; cwnd growth continues.

Line:

receive_ack(ack_num=8)
cwnd = cwnd + 1

💡 TCP AIMD steadily increases cwnd to maximize throughput without causing congestion.

cwnd = 1  # STEP 1: Initialize congestion window
ssthresh = 8
next_seq_num = 1
ack_expected = 1

# STEP 2: Send first packet
send_packet(seq_num=next_seq_num)

# STEP 3-4: Receiver processes packet and sends ACK
# STEP 5: Sender receives ACK and increases cwnd
if ack_num > ack_expected:
    ack_expected = ack_num
    if cwnd < ssthresh:
        cwnd += 1  # additive increase

# STEP 6: Send packets up to cwnd
while next_seq_num < ack_expected + cwnd:
    next_seq_num += 1
    send_packet(seq_num=next_seq_num)

# Repeat steps for receiving ACKs and increasing cwnd
# Final step: all packets acknowledged

📊

TCP Flow Control - Sliding Window & Congestion Control (AIMD) - Watch the Algorithm Execute, Step by Step

Watching the packet flow and window adjustments step-by-step reveals how TCP controls data transmission to avoid congestion and ensure reliable delivery, which is hard to grasp from code alone.

Initialized sender cwnd=1, ssthresh=8; receiver ready for seq=1

Hop: 0

Sender

Receiver

Router1

Packet seq=1 sent, window size limits to 1 packet in flight

Hop: 1

Sender

Receiver

Router1

📦Packet

↗ fromsender

↘ toreceiver

📄 payloadseq=1

🔌 protocolTCP

🚩 flagsDATA

src→10.0.0.1:50000

dst→10.0.0.2:80

data→seq=1

flags→DATA

Sent: seq=1 from sender to receiver

Receiver processed seq=1, preparing ACK for seq=2

Hop: 2

Sender

Receiver

Router1

📦Packet

↗ fromrouter1

↘ toreceiver

📄 payloadseq=1

🔌 protocolTCP

🚩 flagsDATA

src→10.0.0.1:50000

dst→10.0.0.2:80

data→seq=1

flags→DATA

Sent: seq=1 from sender to receiver

Received: seq=1 at receiver

ACK for seq=2 sent, signaling successful receipt of seq=1

Hop: 3

Sender

Receiver

Router1

📦Packet

↗ fromreceiver

↘ tosender

📄 payloadack=2

🔌 protocolTCP

🚩 flagsACK

src→10.0.0.2:80

dst→10.0.0.1:50000

data→ack=2

flags→ACK

Sent: seq=1 from sender to receiver

Received: seq=1 at receiver

Sent: ack=2 from receiver to sender

Sender received ACK=2, cwnd increased from 1 to 2 (additive increase)

Hop: 4

Sender

Receiver

Router1

📦Packet

↗ fromrouter1

↘ tosender

📄 payloadack=2

🔌 protocolTCP

🚩 flagsACK

src→10.0.0.2:80

dst→10.0.0.1:50000

data→ack=2

flags→ACK

Received: seq=1 at receiver

Sent: ack=2 from receiver to sender

Received: ack=2 at sender

Sender sent packets seq=2 and seq=3 filling cwnd=2

Hop: 1

Sender

Receiver

Router1

📦Packet

↗ fromsender

↘ toreceiver

📄 payloadseq=2

🔌 protocolTCP

🚩 flagsDATA

src→10.0.0.1:50000

dst→10.0.0.2:80

data→seq=2

flags→DATA

Received: ack=2 at sender

Sent: seq=2 from sender to receiver

Sent: seq=3 from sender to receiver

Receiver processed seq=2, preparing ACK for seq=4

Hop: 2

Sender

Receiver

Router1

📦Packet

↗ fromrouter1

↘ toreceiver

📄 payloadseq=2

🔌 protocolTCP

🚩 flagsDATA

src→10.0.0.1:50000

dst→10.0.0.2:80

data→seq=2

flags→DATA

Sent: seq=2 from sender to receiver

Sent: seq=3 from sender to receiver

Received: seq=2 at receiver

ACK for seq=4 sent, acknowledging packets 2 and 3

Hop: 3

Sender

Receiver

Router1

📦Packet

↗ fromreceiver

↘ tosender

📄 payloadack=4

🔌 protocolTCP

🚩 flagsACK

src→10.0.0.2:80

dst→10.0.0.1:50000

data→ack=4

flags→ACK

Sent: seq=3 from sender to receiver

Received: seq=2 at receiver

Sent: ack=4 from receiver to sender

Sender received ACK=4, cwnd increased from 2 to 3 (additive increase)

Hop: 4

Sender

Receiver

Router1

📦Packet

↗ fromrouter1

↘ tosender

📄 payloadack=4

🔌 protocolTCP

🚩 flagsACK

src→10.0.0.2:80

dst→10.0.0.1:50000

data→ack=4

flags→ACK

Received: seq=2 at receiver

Sent: ack=4 from receiver to sender

Received: ack=4 at sender

Sender sent packets seq=4, 5, 6 filling cwnd=3

Hop: 1

Sender

Receiver

Router1

📦Packet

↗ fromsender

↘ toreceiver

📄 payloadseq=4

🔌 protocolTCP

🚩 flagsDATA

src→10.0.0.1:50000

dst→10.0.0.2:80

data→seq=4

flags→DATA

Sent: seq=4 from sender to receiver

Sent: seq=5 from sender to receiver

Sent: seq=6 from sender to receiver

Receiver processed seq=4, preparing ACK for seq=7

Hop: 2

Sender

Receiver

Router1

📦Packet

↗ fromrouter1

↘ toreceiver

📄 payloadseq=4

🔌 protocolTCP

🚩 flagsDATA

src→10.0.0.1:50000

dst→10.0.0.2:80

data→seq=4

flags→DATA

Sent: seq=5 from sender to receiver

Sent: seq=6 from sender to receiver

Received: seq=4 at receiver

ACK for seq=7 sent, acknowledging packets 4, 5, 6

Hop: 3

Sender

Receiver

Router1

📦Packet

↗ fromreceiver

↘ tosender

📄 payloadack=7

🔌 protocolTCP

🚩 flagsACK

src→10.0.0.2:80

dst→10.0.0.1:50000

data→ack=7

flags→ACK

Sent: seq=6 from sender to receiver

Received: seq=4 at receiver

Sent: ack=7 from receiver to sender

Sender received ACK=7, cwnd increased from 3 to 4 (additive increase)

Hop: 4

Sender

Receiver

Router1

📦Packet

↗ fromrouter1

↘ tosender

📄 payloadack=7

🔌 protocolTCP

🚩 flagsACK

src→10.0.0.2:80

dst→10.0.0.1:50000

data→ack=7

flags→ACK

Received: seq=4 at receiver

Sent: ack=7 from receiver to sender

Received: ack=7 at sender

Sender sent packet seq=7 filling cwnd=4

Hop: 1

Sender

Receiver

Router1

📦Packet

↗ fromsender

↘ toreceiver

📄 payloadseq=7

🔌 protocolTCP

🚩 flagsDATA

src→10.0.0.1:50000

dst→10.0.0.2:80

data→seq=7

flags→DATA

Sent: ack=7 from receiver to sender

Received: ack=7 at sender

Sent: seq=7 from sender to receiver

Receiver processed seq=7, preparing ACK for seq=8

Hop: 2

Sender

Receiver

Router1

📦Packet

↗ fromrouter1

↘ toreceiver

📄 payloadseq=7

🔌 protocolTCP

🚩 flagsDATA

src→10.0.0.1:50000

dst→10.0.0.2:80

data→seq=7

flags→DATA

Received: ack=7 at sender

Sent: seq=7 from sender to receiver

Received: seq=7 at receiver

Final ACK for seq=8 sent, confirming all packets received

Hop: 3

Sender

Receiver

Router1

📦Packet

↗ fromreceiver

↘ tosender

📄 payloadack=8

🔌 protocolTCP

🚩 flagsACK

src→10.0.0.2:80

dst→10.0.0.1:50000

data→ack=8

flags→ACK

Sent: seq=7 from sender to receiver

Received: seq=7 at receiver

Sent: ack=8 from receiver to sender

Sender received final ACK=8, cwnd increased from 4 to 5

Hop: 4

Sender

Receiver

Router1

📦Packet

↗ fromrouter1

↘ tosender

📄 payloadack=8

🔌 protocolTCP

🚩 flagsACK

src→10.0.0.2:80

dst→10.0.0.1:50000

data→ack=8

flags→ACK

Received: seq=7 at receiver

Sent: ack=8 from receiver to sender

Received: ack=8 at sender

Key Takeaways

✓ TCP starts with a small congestion window and cautiously probes network capacity.

This cautious start prevents overwhelming the network and causing congestion early on.

✓ Additive Increase Multiplicative Decrease (AIMD) allows TCP to grow cwnd linearly when no loss occurs.

Watching cwnd increase step-by-step shows how TCP balances throughput and congestion avoidance.

✓ Cumulative ACKs efficiently confirm receipt of multiple packets, enabling sliding window advancement.

Visualizing ACK numbers clarifies how TCP confirms data receipt and controls flow.

Practice

1. When a user requests a web page through a CDN, what is the correct sequence of events if the requested content is not present in the edge cache?

easy

A. Edge server returns an error; user retries directly to origin server

B. Edge server serves stale cached content while asynchronously fetching fresh content

C. DNS server redirects user to origin server bypassing edge server

D. Edge server forwards request to origin server, caches response, then serves user

Solution

1. Step 1: User request reaches edge server

   The edge server checks its cache for the requested content.

2. Step 2: Cache miss triggers origin fetch

   If content is missing, the edge server forwards the request to the origin server.

3. Step 3: Edge server caches the origin response

   Once the origin server responds, the edge server caches the content for future requests.

4. Step 4: Edge server serves content to user

   The user receives the content from the edge server, reducing latency for subsequent requests.

5. Final Answer:

   Option D -> Option D

6. Quick Check:

   Edge servers act as intermediaries that fetch and cache content on cache misses.

Hint: Cache miss -> edge fetches origin -> caches -> serves user

Common Mistakes:

• Assuming edge server returns error on cache miss
• Thinking DNS redirects user directly to origin
• Believing stale content is served without user awareness

2. You want to prevent unauthorized access to your internal network by filtering incoming and outgoing traffic based on IP addresses and ports. Which network component is best suited for this task?

easy

A. Proxy server acting as an intermediary for client requests

B. Firewall filtering traffic based on rules

C. Reverse proxy optimizing server load

D. Content Delivery Network (CDN) caching static content

Solution

1. Step 1: Identify the role of each component

   Firewalls are designed to filter network traffic based on IP addresses, ports, and protocols, enforcing security policies.

2. Step 2: Understand Proxy and Reverse Proxy roles

   Proxies forward client requests but do not primarily filter traffic at the network level; reverse proxies handle server-side requests and optimize load.

3. Step 3: CDN role

   CDNs cache content to improve performance but do not filter traffic for security.

4. Final Answer:

   Option B -> Option B

5. Quick Check:

   Firewall is the component that filters traffic based on rules [OK]

Hint: Firewall filters traffic; proxies forward requests.

Common Mistakes:

• Confusing proxy with firewall as a security filter
• Assuming reverse proxy filters traffic like a firewall

3. In which scenario is HTTPS preferred over HTTP for client-server communication?

easy

A. When the client and server are on the same trusted local network

B. When sensitive data like passwords or credit card numbers are transmitted

C. When the server wants to reduce latency by avoiding encryption overhead

D. When the client only needs to fetch static public content like images

Solution

1. Step 1: Understand the purpose of HTTPS

   HTTPS encrypts data to protect confidentiality and integrity, especially for sensitive information.

2. Step 2: Analyze each option

   A: On a trusted local network, encryption may be less critical, so HTTP might suffice.
   B: Sensitive data requires encryption to prevent eavesdropping, so HTTPS is necessary.
   C: HTTPS adds overhead; avoiding it to reduce latency sacrifices security.
   D: Static public content does not require encryption, so HTTP is often acceptable.

3. Final Answer:

   Option B -> Option B

4. Quick Check:

   HTTPS is essential when transmitting sensitive data to ensure security.

Hint: Use HTTPS whenever data confidentiality matters

Common Mistakes:

• Assuming HTTPS is always needed regardless of data sensitivity
• Believing HTTPS always causes unacceptable latency
• Thinking HTTP is fine for sensitive data on any network

4. Which of the following is a limitation of using a proxy server for improving network security compared to a firewall?

medium

A. Proxy servers cannot filter traffic based on IP addresses and ports

B. Proxy servers cannot cache content to improve performance

C. Proxy servers introduce significant latency due to encryption overhead

D. Proxy servers block all incoming traffic by default

Solution

1. Step 1: Proxy server capabilities

   Proxy servers act as intermediaries forwarding client requests but typically do not filter traffic at the IP/port level.

2. Step 2: Firewall capabilities

   Firewalls filter traffic based on IP addresses, ports, and protocols, providing network-level security.

3. Step 3: Evaluate other options

   Proxy servers can cache content (contradicts C), do not block all incoming traffic by default (contradicts D), but may introduce latency due to encryption overhead in some cases.

4. Final Answer:

   Option C -> Option C

5. Quick Check:

   Proxy servers may introduce latency due to encryption overhead, unlike firewalls [OK]

Hint: Proxy forwards requests; firewall filters traffic.

Common Mistakes:

• Assuming proxies filter traffic like firewalls
• Confusing caching capabilities of proxies

5. Why is it generally discouraged to use POST for operations that are intended to be idempotent, such as updating a user profile repeatedly with the same data?

medium

A. Because POST requests are cached by default, leading to stale data issues.

B. Because POST always deletes the resource before updating it.

C. Because POST cannot carry a request body, limiting update capabilities.

D. Because POST is not idempotent, repeated identical requests may cause unintended side effects.

Solution

1. Step 1: Recall idempotency definition

   An idempotent method produces the same result no matter how many times it is repeated.

2. Step 2: Analyze POST properties

   POST is not idempotent; repeated identical POSTs can create multiple resources or side effects.

3. Step 3: Evaluate options

   Because POST is not idempotent, repeated identical requests may cause unintended side effects correctly identifies the non-idempotent nature of POST. Others are factually incorrect.

4. Final Answer:

   Option D -> Option D

5. Quick Check:

   POST is not idempotent, so using it for idempotent operations risks unintended consequences.

Hint: POST ≠ idempotent; PUT and DELETE are idempotent

Common Mistakes:

• Thinking POST is cached by default (it is not)
• Believing POST cannot carry a body (it can)
• Assuming POST deletes resources before updating