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

🎯

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

mediumNETWORKSAmazonGoogleFlipkart

Imagine streaming a live video where the sender must adjust its sending rate dynamically to avoid overwhelming the network or the receiver’s buffer, ensuring smooth playback without pauses or crashes.

💡 Beginners often confuse flow control with congestion control, thinking both regulate the same thing, but they actually address different problems-receiver buffer capacity vs. network congestion.

📋

Interview Question

Explain how TCP uses sliding window for flow control and how AIMD (Additive Increase Multiplicative Decrease) is applied in TCP congestion control. What are the differences between flow control and congestion control in TCP?

Sliding window mechanism for flow controlTCP congestion control using AIMDDifference between flow control and congestion control

💡

Scenario & Trace

ScenarioA client downloads a large file from a server over a network with variable bandwidth and latency.

1. Server sends data packets up to the receiver’s advertised window size (flow control). 2. Receiver acknowledges received packets and updates the window size based on its buffer availability. 3. Server increases its congestion window gradually (additive increase) when acknowledgments arrive without loss. 4. Upon detecting packet loss (timeout or triple duplicate ACKs), server reduces congestion window multiplicatively (multiplicative decrease) to avoid network congestion. 5. This cycle repeats, balancing throughput and network stability.

ScenarioTwo processes communicate over TCP where the receiver’s buffer is small but the network is fast.

1. Receiver advertises a small window size limiting sender’s outstanding unacknowledged data (flow control). 2. Sender respects this window and sends only allowed data. 3. Even if network can handle more data, sender cannot exceed receiver’s window, preventing buffer overflow. 4. Congestion control mechanisms operate independently to avoid network congestion.

• Receiver’s advertised window size is zero → sender must stop sending and periodically probe for window update
• Network congestion causes packet loss → triggers multiplicative decrease in congestion window
• Receiver’s buffer is large but network is congested → flow control window is large but congestion window limits throughput

⚠️

Common Mistakes

Confusing flow control with congestion control

Interviewer thinks candidate lacks fundamental understanding of TCP mechanisms.

✅ Remember flow control manages receiver buffer limits; congestion control manages network capacity.

Assuming sliding window alone controls congestion

Interviewer doubts candidate’s grasp of network dynamics and TCP’s dual-window approach.

✅ Clarify that sliding window is for flow control; congestion window and AIMD handle congestion.

Not mentioning multiplicative decrease on packet loss

Interviewer suspects incomplete knowledge of AIMD and TCP’s congestion response.

✅ Always include that congestion window halves on loss to reduce congestion.

Ignoring zero window size scenario

Interviewer thinks candidate misses important edge cases affecting transmission.

✅ Explain that sender must stop sending and probe periodically until window opens.

🧠

Basic Definition - What It Is

💡 This level covers the fundamental concepts you must know to answer basic interview questions on TCP flow and congestion control.

Intuition

TCP uses sliding window to ensure the receiver is not overwhelmed, and AIMD to adjust sending rate based on network conditions.

Explanation

TCP flow control uses a sliding window mechanism where the receiver advertises how much data it can accept, preventing buffer overflow. The sender can only send data within this window before waiting for acknowledgments. Congestion control, on the other hand, manages the sender’s rate to avoid overwhelming the network. AIMD is a strategy where the sender increases its congestion window additively when the network is stable and decreases it multiplicatively upon detecting congestion, balancing throughput and fairness.

Memory Hook

💡 Think of flow control as the receiver holding a 'bucket' that limits how much water (data) it can hold, while congestion control is the sender adjusting the faucet flow based on pipe pressure.

Interview Questions

❓ What is the purpose of the sliding window in TCP?

• It controls the amount of data the sender can transmit before receiving an acknowledgment.
• It prevents the receiver’s buffer from overflowing.

❓ What does AIMD stand for and why is it used?

• Additive Increase Multiplicative Decrease.
• Used to adjust the congestion window to probe for available bandwidth and reduce sending rate on congestion.

⏱

Depth Level

Interview Time30 seconds

Depthbasic

Covers fundamental definitions and purpose; sufficient for screening rounds or quick conceptual questions.

Interview Target: Minimum floor - never go below this

Knowing only this will help you clear initial rounds but may not suffice for detailed technical discussions.

🧠

Mechanism Depth - How It Works

💡 This level explains the internal workings and interplay between flow control and congestion control, expected in product company interviews.

Intuition

TCP dynamically manages two windows - the receiver’s advertised window for flow control and the congestion window for network conditions - combining them to decide how much data to send.

Explanation

The sliding window flow control mechanism allows the receiver to advertise a window size indicating how many bytes it can accept without overflow. The sender maintains a send window limited by the minimum of the receiver’s advertised window and the congestion window. The congestion window is adjusted using AIMD: it increases linearly (additive increase) each round-trip time when no loss is detected, probing for more bandwidth, and decreases multiplicatively (usually halving) upon detecting packet loss, signaling congestion. TCP also uses slow start to exponentially increase the congestion window initially until it reaches a threshold, then switches to AIMD. This dual-window approach ensures that the sender neither overwhelms the receiver nor the network. The interaction between these windows determines the actual sending rate.

Memory Hook

💡 Imagine driving a car where the receiver’s window is the speed limit set by the road (receiver’s capacity), and congestion control is the driver adjusting speed based on traffic conditions (network congestion).

Interview Questions

❓ How does TCP decide the amount of data to send at any time?

• It uses the minimum of the receiver’s advertised window and the congestion window.
• The sender cannot send more data than allowed by either window.

❓ What happens to the congestion window when packet loss is detected?

• It decreases multiplicatively, typically halving the window size.
• This reduces sending rate to alleviate congestion.

❓ Explain the slow start phase in TCP congestion control.

• Initially, congestion window grows exponentially to quickly find available bandwidth.
• Once a threshold is reached, it switches to additive increase.

⏱

Depth Level

Interview Time2-3 minutes

Depthintermediate

Demonstrates understanding of internal TCP mechanisms and their interplay; suitable for FAANG on-site interviews.

Interview Target: Target level for FAANG on-sites

Mastering this level distinguishes you from most candidates and prepares you for deep technical discussions.

📊

Explanation Depth Levels

💡 Choose your explanation depth based on interview stage and company expectations.

Level	Interview Time	Suitable For	Risk
Basic Definition	30s	Screening call or quick conceptual questions	Too shallow for on-site interviews; may fail detailed technical probes
Mechanism Depth	2-3 minutes	On-site interviews at product companies like FAANG	Requires good understanding; insufficient detail may lose points

💼

Interview Strategy

💡 Use this guide to structure your explanation clearly and confidently before every mock or real interview.

How to Present

Start with a clear definition of flow control and congestion control.Give a relatable analogy or example to illustrate the concepts.Explain the sliding window mechanism and how AIMD adjusts the congestion window.Discuss edge cases like zero window size and packet loss scenarios.

Time Allocation

Definition: 30s → Example: 1min → Mechanism: 2min → Edge cases: 30s. Total ~4min

What the Interviewer Tests

Interviewer tests your ability to distinguish flow control from congestion control, explain their mechanisms, and reason about their interaction and edge cases.

Common Follow-ups

• What happens if the receiver’s window size is zero?
• How does TCP recover from congestion after multiplicative decrease?

💡 These follow-ups check your understanding of TCP’s robustness and recovery mechanisms.

🔍

Pattern Recognition

When to Use

When asked about TCP’s reliability, performance optimization, or network behavior under load.

Signature Phrases

'Explain TCP flow control and congestion control''Compare sliding window and congestion window''What happens when packet loss occurs in TCP?'

NOT This Pattern When

Similar Problems

Practice

1. Trace the sequence of steps during a TLS handshake when a client connects to an HTTPS server.

easy

A. Client sends ClientHello, server responds with ServerHello and certificate, client verifies certificate, client sends encrypted pre-master secret, server decrypts it, both derive symmetric keys

B. Client sends encrypted data, server responds with certificate, then symmetric key is exchanged

C. Client sends HTTP request, server sends certificate, client sends symmetric key in plaintext, handshake completes

D. Client sends ClientHello, server sends ServerHello, handshake completes without certificate exchange

Solution

1. Step 1: Identify the TLS handshake flow

   The handshake starts with ClientHello, followed by ServerHello and certificate, then client verifies certificate, sends encrypted pre-master secret, and both derive symmetric keys.

2. Step 2: Evaluate each option

   A: Correct sequence including ClientHello, ServerHello, certificate exchange, verification, encrypted pre-master secret, and key derivation.
   B: Incorrect order and missing ClientHello/ServerHello steps.
   C: Client sends HTTP request too early and symmetric key is never sent in plaintext.
   D: Certificate exchange is mandatory for authentication, so this is incomplete.

3. Final Answer:

   Option A -> Option A

4. Quick Check:

   Remember the handshake involves hello messages, certificate exchange, key exchange, and symmetric key derivation.

Hint: TLS handshake = Hello messages + certificate + encrypted key exchange

Common Mistakes:

• Confusing when the certificate is sent
• Assuming symmetric keys are exchanged in plaintext
• Skipping certificate verification step

2. Which of the following statements best explains why recursive DNS queries can increase latency compared to iterative queries?

medium

A. Recursive queries always bypass DNS caching, causing repeated full lookups.

B. Recursive queries use UDP instead of TCP, which increases packet loss and retransmissions.

C. Recursive queries are sent directly to the authoritative server, which is slower than querying root servers first.

D. Recursive queries require the DNS server to perform multiple lookups on behalf of the client, adding processing time and network hops.

Solution

1. Step 1: Understand recursive query behavior

   Recursive DNS servers perform all necessary lookups to resolve a domain fully before responding.

2. Step 2: Impact on latency

   This means the recursive server makes multiple network requests, adding processing and network delay.

3. Step 3: Why other options are incorrect

   Recursive queries do use caching (A is false), do not bypass root servers (C is false), and use UDP or TCP depending on size but that is unrelated to latency increase (D is false).

4. Final Answer:

   Option D -> Option D

5. Quick Check:

   Recursive queries add latency due to multiple lookups -> correct

Hint: Recursive queries do more work per request, increasing latency.

Common Mistakes:

• Believing recursive queries bypass caching
• Thinking recursive queries contact authoritative servers first
• Confusing transport protocols with query type

3. What is a key limitation of Port Address Translation (PAT) when many internal hosts simultaneously initiate outbound connections to the internet?

medium

A. PAT cannot translate destination IP addresses, so inbound connections are impossible

B. PAT requires a unique public IP per internal host, increasing IP address consumption

C. PAT can run out of available source ports, limiting the number of simultaneous connections

D. PAT causes all internal hosts to share the same source port, causing packet collisions

Solution

1. Step 1: Recall PAT function

   PAT maps multiple internal IP:port pairs to a single public IP with unique source ports.

2. Step 2: Identify limitation

   Since TCP/UDP ports are 16-bit, only ~65,000 ports are available per public IP, limiting simultaneous connections.

3. Step 3: Analyze options

   PAT can run out of available source ports, limiting the number of simultaneous connections correctly identifies port exhaustion. PAT requires a unique public IP per internal host, increasing IP address consumption is false; PAT uses one public IP for many hosts. PAT cannot translate destination IP addresses, so inbound connections are impossible is unrelated to PAT's outbound translation. PAT causes all internal hosts to share the same source port, causing packet collisions is false; PAT assigns unique ports to avoid collisions.

4. Final Answer:

   Option C -> Option C

5. Quick Check:

   PAT port exhaustion limits simultaneous connections [OK]

Hint: PAT multiplexes ports but port space is finite

Common Mistakes:

• Thinking PAT needs multiple public IPs
• Confusing PAT with DNAT limitations
• Believing PAT uses the same source port for all hosts

4. In a network where ARP spoofing attacks are frequent, which advanced mitigation technique can be employed to detect and prevent such attacks beyond static ARP entries?

hard

A. Implementing dynamic ARP inspection (DAI) on switches to validate ARP packets against a trusted database.

B. Disabling ARP entirely and relying solely on IP addresses for communication.

C. Using DHCP snooping to assign static IP addresses to all devices.

D. Increasing the ARP cache timeout to reduce ARP traffic.

Solution

1. Step 1: Understand advanced ARP spoofing mitigation

   Dynamic ARP Inspection (DAI) is a security feature on switches that intercepts ARP packets and verifies them against a trusted binding database.

2. Step 2: Why not disabling ARP?

   ARP is essential for IP-to-MAC resolution; disabling it breaks local communication.

3. Step 3: DHCP snooping is complementary but not sufficient

   DHCP snooping helps build trusted bindings but does not directly inspect ARP packets.

4. Step 4: Increasing ARP cache timeout worsens spoofing risk

   Longer cache times mean stale or poisoned entries persist longer.

5. Final Answer:

   Option A -> Option A

6. Quick Check:

   DAI validates ARP packets to prevent spoofing effectively [OK]

Hint: DAI inspects ARP packets dynamically to prevent spoofing [OK]

Common Mistakes:

• Thinking ARP can be disabled safely
• Confusing DHCP snooping with ARP inspection
• Believing longer ARP cache timeout improves security

5. If a network uses IPv6-only hosts but needs to access IPv4-only services, which transition technique would best handle DNS resolution and packet translation without requiring dual-stack on hosts?

hard

A. Dual-stack deployment on all hosts

B. Tunneling IPv6 packets over IPv4 infrastructure

C. NAT64 combined with DNS64 to translate DNS queries and packets

D. Manual static mapping of IPv6 addresses to IPv4 addresses

Solution

1. Step 1: Understand the scenario

   IPv6-only hosts need to reach IPv4-only services without dual-stack.

2. Step 2: Analyze options

   Dual-stack deployment on all hosts requires dual-stack, which is excluded. Tunneling IPv6 packets over IPv4 infrastructure tunnels IPv6 over IPv4 but does not solve DNS translation. NAT64 combined with DNS64 to translate DNS queries and packets correctly combines NAT64 (packet translation) and DNS64 (DNS query translation) to enable IPv6-only hosts to access IPv4 services transparently. Manual static mapping of IPv6 addresses to IPv4 addresses is impractical and not scalable.

3. Final Answer:

   Option C -> Option C

4. Quick Check:

   NAT64/DNS64 enables IPv6-only hosts to access IPv4 services without dual-stack.

Hint: NAT64 + DNS64 = IPv6-only hosts reach IPv4 services [OK]

Common Mistakes:

• Assuming tunneling solves DNS translation
• Thinking dual-stack is mandatory for IPv6-to-IPv4 access
• Believing manual mappings are practical