Imagine you're trying to fill a water glass from a firehose — without some way to control the flow, you'll end up with a mess (and a broken glass). That's exactly the problem TCP flow control solves: preventing a fast sender from overwhelming a slow receiver. On the CCNA 200-301 exam, understanding TCP windowing and flow control is essential for objective 1.5 (Compare TCP to UDP) and for troubleshooting application performance issues in real networks. This chapter will give you the exact mechanism, the RFC-mandated timers, and the Cisco CLI verification commands you need.
Jump to a section
Think of TCP flow control like the baggage carousel at a busy airport. The sender is the baggage handlers loading suitcases onto the carousel. The receiver is you, standing at the carousel waiting to grab your bags. You have a finite amount of space on the floor next to you — let's say you can hold five suitcases before you start tripping over them. This is your 'receive window.' As bags come around, you pick them up and move them to your space. When your space is full, you need the handlers to stop sending more bags until you've cleared some space. In TCP, the receiver advertises a 'window size' in every ACK segment, telling the sender how many bytes it can accept. If the receiver is slow (maybe you're checking your phone), it advertises a smaller window. If it's fast, it advertises a larger window. The sender must never send more data than the receiver's advertised window. If it does, the receiver will drop the excess, and the sender has to retransmit — wasting time and bandwidth. The airport analogy also covers 'window scaling': when the carousel is huge (like at a major hub), the baggage handlers can send more bags at once. TCP uses a scaling factor to multiply the window size, allowing for windows larger than 65,535 bytes. This is critical for high-latency links (like transatlantic flights) where you want to keep the pipe full. And just like baggage handlers need to know when the carousel jams (congestion), TCP uses congestion control algorithms (like slow start) to detect and react to network congestion. The key point: flow control is about the receiver's ability to keep up, while congestion control is about the network's capacity. In the exam, don't confuse the two!
What is TCP Flow Control and Why Does It Exist?
TCP (Transmission Control Protocol) provides reliable, connection-oriented data delivery. One of its core responsibilities is flow control — preventing the sender from transmitting data faster than the receiver can process it. Without flow control, a fast sender could overflow the receiver's buffer, causing dropped segments, retransmissions, and wasted bandwidth. Flow control is distinct from congestion control, which prevents the sender from overwhelming the network itself. On the CCNA exam, you must be able to distinguish between the two and explain how the sliding window mechanism works.
The Sliding Window Mechanism
TCP flow control uses a sliding window algorithm. The receiver advertises a receive window (rwnd) in every TCP segment it sends back to the sender. The rwnd indicates the number of bytes the receiver is willing to accept at that moment. The sender maintains a send window that cannot exceed the receiver's rwnd. As the sender transmits data, the window slides forward; as the receiver acknowledges data, the window opens up again.
Key points:
The window size is a 16-bit field in the TCP header, so the maximum value is 65,535 bytes.
To support larger windows (needed for high-bandwidth, high-latency links), TCP uses Window Scaling (RFC 7323). The window scale option is negotiated during the three-way handshake. The scale factor (0-14) multiplies the window field, allowing windows up to 1 GB.
The sender can send up to the full window size without waiting for an ACK. This is called pipelining and improves throughput.
Step-by-Step Flow Control Operation
Connection Establishment: During the three-way handshake, both devices announce their initial receive windows. For example, host A sends a SYN with an rwnd of 65,535. Host B responds with SYN-ACK with its own rwnd. The window scale option can also be negotiated here.
Data Transmission: Host A sends a burst of data equal to the size of the send window (which is the minimum of the receiver's rwnd and the congestion window from congestion control). Host B receives the data, processes it, and sends ACKs. Each ACK includes the current rwnd.
Window Update: As Host B's application consumes data, the buffer empties, and Host B can advertise a larger rwnd. If the application is slow, the rwnd shrinks. If the rwnd reaches zero, Host A must stop sending. Host B then sends a window update (a pure ACK with a non-zero rwnd) when buffer space becomes available.
Zero Window Probing: To prevent deadlock when the receiver's window is zero, the sender periodically sends a zero window probe (a single byte of data) to force the receiver to re-advertise its window. The probe interval doubles (like TCP retransmission) up to a maximum of 60 seconds.
Important Timers and Defaults
Persist Timer: When the sender receives a zero-window advertisement, it starts a persist timer (default 1.5 seconds on Cisco IOS) to send zero window probes. If no response, it retries with exponential backoff up to 60 seconds.
Window Size Default: Cisco IOS defaults to a receive window of 65,535 bytes (16,383 segments for MSS of 1460). Modern hosts use window scaling to support up to 1 GB.
Window Scale Factor: Negotiated during handshake. The scale factor is the number of bits to left-shift the 16-bit window field. A factor of 7 means window = window_field * 128.
Verification with Cisco IOS
To see TCP connection details including window size and scaling, use:
R1# show tcp brief
TCB Local Address Foreign Address (state)
0x56000001 192.168.1.1.23 192.168.1.2.34567 ESTABFor detailed information on a specific connection:
R1# show tcp tcb 0x56000001
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 192.168.1.1, Local port: 23
Foreign host: 192.168.1.2, Foreign port: 34567
Send-Q: 0, Receive-Q: 0
Send buffer: 32768 bytes, Receive buffer: 32768 bytes
Send window: 32768 bytes, Receive window: 32768 bytes
Scale factor: 1 (scale factor: 1)Note the Scale factor line — this shows the negotiated window scaling factor. The actual window size is the displayed value multiplied by the scale factor.
Interaction with Congestion Control
Flow control (receiver-driven) and congestion control (network-driven) work together. The sender's effective window is the minimum of the receiver's advertised window (rwnd) and the congestion window (cwnd). This is often called the swnd (send window). The cwnd is dynamically adjusted by algorithms like slow start, congestion avoidance, fast retransmit, and fast recovery. On the exam, you may be asked to calculate the maximum number of segments that can be sent before an ACK is required, given the window size and MSS.
Common Exam Scenarios
Identifying flow control vs. congestion control
Understanding that a window size of 0 stops the sender
Knowing that window scaling is negotiated during the three-way handshake
Interpreting 'show tcp' output to find the receive window
Recognizing that TCP flow control operates end-to-end, not hop-by-hop (unlike Ethernet flow control)
Now that you understand the mechanism, let's walk through the exact steps a TCP sender and receiver follow during flow control.
Receiver Advertises Window
During the TCP three-way handshake, the receiver includes its initial receive window (rwnd) in the SYN-ACK segment. For example, if the receiver has a buffer of 64 KB, it might advertise rwnd = 65535 bytes. This value is placed in the 16-bit Window field of the TCP header. If both hosts support window scaling, they also exchange the Window Scale option (e.g., scale factor = 2, meaning the window field value is multiplied by 4). The sender records this window as the maximum it can send without receiving an ACK.
Sender Transmit Data Burst
The sender can now transmit up to the advertised window size (minus any data already sent but not yet acknowledged). For example, if rwnd = 65535 and the MSS is 1460, the sender can send up to 44 segments (65535 / 1460 ≈ 44) in a burst. As segments are sent, the sender's available window shrinks. The sender must not exceed the window. This pipelining improves throughput compared to stop-and-wait.
Receiver Processes and ACKs
The receiver places incoming data into its receive buffer. The application reads data from the buffer. As the application consumes data, the buffer empties, and the receiver can advertise a larger window. Each ACK sent back to the sender includes the current rwnd. If the application is slow, the buffer fills, and the receiver advertises a smaller window. If the buffer becomes full, rwnd = 0.
Window Update or Zero Window
If the receiver's buffer is full (rwnd = 0), it sends a pure ACK with window field = 0. The sender must stop transmitting data. The receiver will later send a window update (an ACK with a non-zero window) when buffer space becomes available. The sender waits for this update before resuming transmission. To avoid deadlock, the sender uses a persist timer to probe the receiver.
Zero Window Probing
When the sender receives a zero-window advertisement, it starts a persist timer (default 1.5 seconds on Cisco IOS). When the timer expires, the sender transmits a zero window probe: a segment containing one byte of new data (to force the receiver to ACK). If the receiver's window is still zero, it responds with another zero-window ACK. The sender then doubles the persist timer (exponential backoff) up to a maximum of 60 seconds. Once the receiver advertises a non-zero window, the sender resumes normal transmission.
Window Scaling for High Performance
For high-bandwidth, high-latency links (e.g., satellite, transoceanic), a window of 65535 bytes is too small to keep the pipe full. The window scaling option (RFC 7323) allows the window field to be multiplied by a scale factor. The scale factor is negotiated during the three-way handshake. For example, a scale factor of 7 means the window field value is left-shifted by 7 bits (multiplied by 128). So a window field of 65535 with scale factor 7 yields an actual window of 8,388,480 bytes (8 MB). This is critical for achieving high throughput on long fat networks (LFNs).
Enterprise Scenario 1: File Transfer over a WAN Link
A multinational company transfers large database backups from a data center in New York to a disaster recovery site in London. The link has a 100 ms round-trip time and 1 Gbps bandwidth. Without window scaling, the maximum throughput is limited by the TCP window: throughput = window / RTT = 65535 bytes / 0.1 s ≈ 5.2 Mbps — far below the link capacity. The network engineer enables window scaling on both endpoints (modern OSes do this by default). With a scale factor of 7, the effective window is 8 MB, giving throughput ≈ 640 Mbps. This single configuration change dramatically improves backup completion times. The engineer verifies window scaling using show tcp tcb on the router or netstat -s on the server.
Enterprise Scenario 2: Server with Slow Application
A web server runs a legacy application that processes requests slowly. Clients connect and send HTTP requests. The server's TCP receive buffer fills up because the application isn't consuming data fast enough. The server advertises a shrinking window until it hits zero. The clients stop sending. The server's persist timer ensures that when the application catches up, the window reopens. Without flow control, the clients would overflow the server's buffer, causing dropped segments and retransmissions. A network engineer might notice high retransmission rates and use show tcp statistics to see the number of zero window advertisements. Tuning the application or increasing the socket buffer size (e.g., ip tcp window-size 65536 on Cisco IOS) can help.
Enterprise Scenario 3: Misconfigured Firewall or Load Balancer
A security appliance strips TCP options, including window scaling. Clients and servers that negotiated window scaling during the handshake may have mismatched expectations. The server might send data at a rate the client cannot handle because the client's actual window is smaller than the server thinks. This causes packet drops and poor performance. Network engineers must ensure that intermediate devices pass TCP options transparently. Using show tcp tcb on routers along the path can reveal the negotiated window scale factor. If the scale factor is 0 on one side but not the other, there's a problem.
Common Misconfiguration: Buffer Bloat
Large buffers in routers can interact poorly with TCP flow control. If a router buffers too much data, TCP's congestion control (which relies on packet loss) may not kick in, leading to high latency (bufferbloat). Engineers use QoS to manage queues and RED (Random Early Detection) to signal congestion before buffers overflow.
Scale and Performance
In large data centers, TCP flow control is critical for storage protocols like iSCSI and NVMe-oF. These protocols rely on TCP's reliability and flow control to prevent data loss. Engineers often tune TCP parameters (window size, scaling, timers) to match the workload. Tools like iperf3, Wireshark, and Cisco's Embedded Packet Capture help diagnose flow control issues.
What Happens When Misconfigured
If window scaling is disabled on one side, the effective window is limited to 65535 bytes, causing poor throughput on high-latency links. If the receiver's buffer is too small, the window frequently goes to zero, causing the sender to stall. This manifests as low throughput and high latency. If the sender ignores the window (a violation of RFC 793), it causes buffer overflow and retransmissions.
What the CCNA 200-301 Tests (Objective 1.5)
The exam expects you to compare TCP and UDP, but specifically for TCP flow control:
Explain the purpose of flow control (prevent receiver overload) vs. congestion control (prevent network overload)
Describe the sliding window mechanism: the receiver advertises a window, the sender cannot exceed it
Identify the window size field in the TCP header (16 bits, max 65535 without scaling)
Know that window scaling is negotiated during the three-way handshake
Understand that a zero window stops the sender, and the persist timer handles probing
Interpret output from show tcp brief and show tcp tcb to find window sizes and scale factors
Top 4 Wrong Answers and Why Candidates Choose Them
"Flow control prevents the sender from overwhelming the network." This is congestion control, not flow control. Candidates confuse the two because both involve windows. Remember: flow control = receiver buffer; congestion control = network capacity.
"The sender advertises the window size." No, the receiver advertises the window. The sender obeys. Candidates often reverse the roles. The window field in the ACK tells the sender how much the receiver can accept.
"The maximum window size is 65,535 bytes." This is true only if window scaling is not used. With scaling, the window can be much larger. The exam may present a scenario with a high-latency link and ask why throughput is low — the answer is often "window scaling is not enabled."
"TCP flow control uses a fixed window size." The window is dynamic — it changes based on the receiver's buffer availability. Candidates may think it's static because they've seen the initial window advertised in the handshake.
Specific Values and Defaults to Memorize
Default receive window on Cisco IOS: 65535 bytes (16,383 segments for MSS 1460)
Window scale factor range: 0-14 (shift count)
Persist timer initial value: 1.5 seconds (on Cisco IOS)
Zero window probe maximum interval: 60 seconds
Window size field: 16 bits
Calculation Traps
You may be asked to calculate the throughput limit given window size and RTT. The formula is: Throughput ≤ Window / RTT. For example, window = 65535 bytes, RTT = 200 ms → throughput ≤ 65535 * 8 / 0.2 ≈ 2.62 Mbps. If the link is 100 Mbps, the bottleneck is the window. The solution is to enable window scaling.
Decision Rule for Scenario Questions
If a question describes a slow receiver causing the sender to pause, the answer involves flow control and the window size. If the question describes network congestion (e.g., dropped packets, high latency), the answer involves congestion control (slow start, congestion avoidance). If the question mentions high latency and low throughput, suspect window scaling.
TCP flow control prevents the sender from overwhelming the receiver's buffer.
The receiver advertises the receive window (rwnd) in every ACK segment.
The window size field is 16 bits, max 65535 bytes without scaling.
Window scaling is negotiated during the three-way handshake using the Window Scale option.
A zero window stops the sender until the receiver sends a window update.
The persist timer (default 1.5s) triggers zero window probes to avoid deadlock.
Flow control is receiver-driven; congestion control is network-driven.
These come up on the exam all the time. Here's how to tell them apart.
TCP Flow Control
Prevents receiver buffer overflow
Uses receiver's advertised window (rwnd)
Receiver-driven: receiver sets the limit
Operates end-to-end
Window can go to zero, stopping sender
TCP Congestion Control
Prevents network overload (router buffers)
Uses congestion window (cwnd)
Sender-driven: sender adjusts based on network feedback
Operates on the path between hosts
Uses slow start, congestion avoidance, fast retransmit
Mistake
Flow control and congestion control are the same thing.
Correct
Flow control prevents receiver overload (receiver buffer); congestion control prevents network overload (router buffers). They use different windows: rwnd vs. cwnd.
Both involve 'windows', so candidates lump them together.
Mistake
The sender advertises the window size.
Correct
The receiver advertises the window size in the TCP header of ACK segments. The sender must not exceed this value.
Candidates think the sender controls the flow because it initiates the connection.
Mistake
The TCP window size is fixed once the connection is established.
Correct
The window is dynamic — it shrinks as the receiver's buffer fills and grows as the application consumes data.
Many study materials show the initial window, leading to the false assumption it's static.
Mistake
Window scaling increases the window size field beyond 16 bits.
Correct
The window field remains 16 bits; the scale factor multiplies the value. The actual window = window_field * 2^scale_factor.
The term 'scaling' suggests the field itself gets larger.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Flow control prevents the sender from overwhelming the receiver's buffer. The receiver advertises a window (rwnd) that the sender must respect. Congestion control prevents the sender from overwhelming the network. The sender maintains a congestion window (cwnd) that it adjusts based on packet loss or ECN. Both windows are combined: the effective send window = min(rwnd, cwnd). On the exam, remember that flow control is about the receiver's capacity, congestion control about the network's capacity.
When the sender receives an ACK with a window of 0, it must stop transmitting data. It starts a persist timer (default 1.5 seconds on Cisco IOS). When the timer expires, it sends a zero window probe: a segment with one byte of data. The receiver responds with its current window. If still zero, the sender doubles the persist timer (exponential backoff) up to a maximum of 60 seconds. This prevents deadlock.
Window scaling allows TCP to use window sizes larger than 65535 bytes. It is defined in RFC 7323. During the three-way handshake, hosts exchange a scale factor (0-14). The actual window is the 16-bit window field left-shifted by the scale factor. For example, scale factor 7 means window = window_field * 128. This is essential for high-bandwidth, high-latency links (long fat networks) to achieve high throughput.
Use the command 'show tcp tcb <tcb>' for a specific connection. Look for the line 'Scale factor: <n>'. If n > 0, scaling is in effect. For example, 'Scale factor: 2' means the window field is multiplied by 4. You can also use 'show tcp brief' to list connections and then get details on one.
Yes. If the receiver's buffer is too small, the window frequently goes to zero, causing the sender to stall. This results in low throughput. Also, if window scaling is not enabled, the window is limited to 65535 bytes, which can be a bottleneck on high-latency links. Network engineers tune socket buffer sizes and enable window scaling to optimize performance.
The default receive window size on Cisco IOS is 65535 bytes (the maximum without scaling). This can be changed with the 'ip tcp window-size' command. The actual window used may be smaller if the receiver's buffer is constrained.
TCP flow control is end-to-end. The receiver advertises its window directly to the sender. Intermediate routers do not modify the window field. This contrasts with Ethernet flow control (IEEE 802.3x), which is hop-by-hop between adjacent switches.
You've just covered TCP Flow Control and Windowing — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?