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. 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. Trace the process of determining the network and host portions of the IP address 192.168.10.25 with subnet mask 255.255.255.240. What is the network address?

easy

A. 192.168.10.240

B. 192.168.10.0

C. 192.168.10.25

D. 192.168.10.16

Solution

1. Step 1: Convert subnet mask to binary

   255.255.255.240 = 11111111.11111111.11111111.11110000

2. Step 2: Convert IP address to binary

   192.168.10.25 = 11000000.10101000.00001010.00011001

3. Step 3: Perform bitwise AND between IP and subnet mask

   Result = 11000000.10101000.00001010.00010000 = 192.168.10.16

4. Step 4: Interpret result

   The network address is 192.168.10.16, which identifies the subnet.

5. Final Answer:

   Option D -> Option D

6. Quick Check:

   Subnet mask 255.255.255.240 divides the last octet into 16-address blocks; 25 falls into 16-31 range [OK]

Hint: Network address = IP AND subnet mask

Common Mistakes:

• Using the IP address itself as the network address
• Using the subnet mask as the network address
• Assuming the network address is always .0

3. Trace the sequence of packets exchanged during the TCP three-way handshake when a client initiates a connection to a server.

easy

A. Client sends ACK, Server replies with SYN, Client sends SYN-ACK

B. Client sends SYN-ACK, Server replies with ACK, Client sends SYN

C. Client sends SYN, Server replies with SYN-ACK, Client sends ACK

D. Client sends SYN, Server replies with ACK, Client sends SYN-ACK

Solution

1. Step 1: Understand the handshake steps

   The client initiates by sending a SYN packet to request connection. The server responds with SYN-ACK to acknowledge and synchronize. The client completes with ACK.

2. Step 2: Evaluate each option

   Client sends SYN, Server replies with SYN-ACK, Client sends ACK correctly follows the SYN -> SYN-ACK -> ACK sequence. Options A, C, and D have the order or packet types mixed up, which breaks the handshake protocol.

3. Final Answer:

   Option C -> Option C

4. Quick Check:

   Remember the handshake as "SYN, SYN-ACK, ACK" in that order.

Hint: Handshake order: SYN -> SYN-ACK -> ACK

Common Mistakes:

• Mixing up who sends SYN-ACK or ACK first
• Assuming ACK comes before SYN-ACK

4. Why is it not advisable to rely solely on ARP cache entries without periodic validation in a network environment?

medium

A. Because ARP cache entries never expire and can cause memory overflow.

B. Because ARP cache entries are only stored on routers, not on hosts.

C. Because stale ARP cache entries can lead to incorrect MAC address mappings, causing packet delivery failures.

D. Because ARP cache entries are encrypted and require decryption overhead.

Solution

1. Step 1: Understand ARP cache purpose

   ARP cache stores IP-to-MAC mappings temporarily to reduce broadcast traffic.

2. Step 2: Why periodic validation?

   Network topology or device changes can make cached entries stale, leading to wrong MAC addresses.

3. Step 3: Why not memory overflow?

   ARP caches have size limits and entries expire; they do not cause memory overflow.

4. Step 4: Encryption is irrelevant

   ARP cache entries are not encrypted; encryption is not part of ARP.

5. Step 5: ARP cache exists on hosts and routers

   Both hosts and routers maintain ARP caches.

6. Final Answer:

   Option C -> Option C

7. Quick Check:

   Stale ARP cache entries cause incorrect MAC mappings and delivery issues [OK]

Hint: ARP cache entries can become stale and must be refreshed [OK]

Common Mistakes:

• Believing ARP cache entries never expire
• Thinking ARP cache entries are encrypted
• Assuming ARP cache only exists on routers

5. Which of the following statements about the scalability and overhead trade-offs between Distance Vector and Link State routing is TRUE?

medium

A. Distance Vector routing scales better in large networks because it floods link state advertisements less frequently

B. Distance Vector routing has lower convergence time but higher memory usage compared to Link State

C. Link State routing requires more memory and CPU but scales better due to faster convergence and less routing loops

D. Link State routing uses less bandwidth overall because it only sends updates when topology changes

Solution

1. Step 1: Understand resource usage

   Link State routing stores the entire network topology, requiring more memory and CPU for Dijkstra's algorithm.

2. Step 2: Analyze scalability and convergence

   Link State converges faster and avoids routing loops better, making it more scalable despite higher resource use.

3. Step 3: Evaluate options

   Distance Vector routing scales better in large networks because it floods link state advertisements less frequently is false because Distance Vector does not flood link state advertisements at all. Distance Vector routing has lower convergence time but higher memory usage compared to Link State is false because Distance Vector generally has slower convergence and lower memory usage. Link State routing uses less bandwidth overall because it only sends updates when topology changes is misleading; Link State floods updates on topology changes, which can be bandwidth intensive.

4. Final Answer:

   Option C -> Option C

5. Quick Check:

   Link State trades higher resource use for better scalability and convergence.

Hint: More CPU/memory but faster convergence -> Link State scales better

Common Mistakes:

• Assuming Distance Vector floods updates like Link State
• Confusing convergence time and memory usage
• Believing Link State sends fewer updates overall