Flow control (stop-and-wait, sliding window) in Computer Networks - Time & Space Complexity
When sending data over a network, flow control methods decide how fast data moves between sender and receiver.
We want to understand how the time to send many packets grows as the number of packets increases.
Analyze the time complexity of sending packets using stop-and-wait and sliding window flow control.
// Stop-and-Wait flow control
for each packet in total_packets:
send(packet)
wait for acknowledgment
// Sliding Window flow control
window_size = W
while packets remain:
send up to W packets without waiting
wait for acknowledgments of sent packets
slide window forward
This code shows two ways to send packets: one waits after each packet, the other sends many before waiting.
Look at what repeats as we send packets.
- Primary operation: Sending packets and waiting for acknowledgments.
- How many times: Stop-and-wait waits after each packet, so it repeats send-and-wait for every packet. Sliding window sends multiple packets before waiting, repeating send-and-wait fewer times.
As the number of packets grows, the total time to send them changes differently for each method.
| Input Size (n) | Stop-and-Wait Approx. Operations | Sliding Window Approx. Operations |
|---|---|---|
| 10 | 10 send-wait cycles | About 2-3 send-wait cycles (if window size ~4-5) |
| 100 | 100 send-wait cycles | About 20-25 send-wait cycles |
| 1000 | 1000 send-wait cycles | About 200-250 send-wait cycles |
Pattern observation: Stop-and-wait grows linearly with packets. Sliding window reduces waiting by grouping packets, so it grows slower in practice.
Time Complexity: O(n)
This means the total time to send packets grows roughly in direct proportion to the number of packets, but sliding window reduces waiting overhead.
[X] Wrong: "Sliding window always sends packets instantly with no waiting, so it has zero delay regardless of packet count."
[OK] Correct: Even sliding window must wait for acknowledgments after sending a group of packets, so waiting still grows with total packets, just less often.
Understanding how flow control affects sending time helps you explain network efficiency and design better communication protocols.
What if we increased the sliding window size to cover all packets at once? How would the time complexity change?
Practice
Solution
Step 1: Understand Stop-and-Wait flow control
Stop-and-Wait sends one packet and waits for an acknowledgment before sending the next packet.Step 2: Compare with other methods
Sliding Window sends multiple packets before waiting, while Multiplexing and Routing are unrelated to flow control.Final Answer:
Stop-and-Wait -> Option AQuick Check:
One packet at a time = Stop-and-Wait [OK]
- Confusing Sliding Window with Stop-and-Wait
- Thinking Multiplexing is a flow control method
- Mixing routing with flow control
Solution
Step 1: Recall sliding window behavior
Sliding Window sends multiple packets before waiting for acknowledgment to improve speed.Step 2: Eliminate incorrect options
Sends one packet and waits for acknowledgment describes Stop-and-Wait. The other options do not describe standard flow control methods.Final Answer:
Sends multiple packets before waiting for acknowledgment -> Option BQuick Check:
Multiple packets sent = Sliding Window [OK]
- Choosing Stop-and-Wait for sliding window question
- Thinking no acknowledgment is used
- Confusing timeout with acknowledgment wait
Solution
Step 1: Understand sliding window acknowledgments
Packets 1 and 2 are acknowledged, so the window slides forward by 2 packets.Step 2: Calculate new window range
Window size is 4, so after acknowledging 1 and 2, sender can send packets 5 and 6 (next two packets).Final Answer:
Packets 5 and 6 -> Option AQuick Check:
Window slides by acknowledged packets = Packets 5 and 6 [OK]
- Trying to resend unacknowledged packets
- Sending too many packets beyond window size
- Not sliding window after acknowledgments
Solution
Step 1: Analyze stop-and-wait behavior
Stop-and-wait waits for acknowledgment before sending next packet; no acknowledgment causes resending.Step 2: Identify cause of no acknowledgment
If acknowledgments are missing, likely the receiver is not sending them or they are lost.Final Answer:
The receiver is not sending acknowledgments -> Option CQuick Check:
No acknowledgment = Resend same packet [OK]
- Blaming sender window size in stop-and-wait
- Confusing sliding window with stop-and-wait
- Assuming multiple packets sent in stop-and-wait
Solution
Step 1: Identify lost packets
Packets 2 and 3 are lost, so they need retransmission.Step 2: Understand acknowledgments impact
Packets 1, 4, and 5 are acknowledged, so only lost packets 2 and 3 must be resent before sending new packets.Final Answer:
Packets 2 and 3 only -> Option DQuick Check:
Retransmit lost packets only = Packets 2 and 3 [OK]
- Retransmitting already acknowledged packets
- Sending new packets before lost ones
- Confusing lost packets with acknowledged packets
Ready to prove it?
Pass the test and this pattern moves unknown
