Computer NetworksFlow Control

TCP Flow Control

LevelIntermediate

Duration60 mins

TopicFlow Control

3 / 5

Window Advertisement

The Language of Capacity

How does a receiver communicate its capacity to a sender across a vast, unpredictable network? Through something deceptively simple: a 16-bit number in every TCP segment . This number—the window advertisement—is the fundamental communication channel through which flow control operates. But simplicity masks sophistication. This window field, combined with optional window scaling, enables TCP to manage flows from a few bytes to terabytes per second across networks spanning the globe. Understanding window advertisement at a deep level reveals how TCP achieves fine-grained, byte-level flow control with minimal overhead. This page examines window advertisement comprehensively: its position in the TCP header, its mathematical semantics, how window scaling extends its range, and the precise rules governing window updates.

What You Will Learn

By the end of this page, you will understand: (1) The TCP header's window field structure and position, (2) The mathematical meaning of window values, (3) Window scaling for high-bandwidth-delay-product networks, (4) When and how window updates are communicated, and (5) The interaction between window advertisement and sender behavior.

The Window Field in the TCP Header

The window advertisement is carried in a dedicated field within the TCP header. Understanding its position and characteristics is fundamental to understanding TCP flow control. TCP Header Layout The TCP header begins with source and destination ports (4 bytes), followed by sequence number (4 bytes), acknowledgment number (4 bytes), and then a byte containing data offset and reserved bits. After the flags byte comes the window field . Window Field Characteristics Size : 16 bits (2 bytes) Position : Bytes 14-15 of the TCP header (0-indexed) Range : 0 to 65,535 bytes (without scaling) Encoding : Unsigned integer, network byte order (big-endian) Always present : The window field exists in every TCP segment, not just ACKs Historical Context When TCP was designed in the late 1970s, a 65,535-byte window seemed ample. Networks were slow, buffers were small, and 64 KB could buffer several seconds of data. The designers could not foresee gigabit networks where 64 KB might represent mere milliseconds of data. This limitation was later addressed by window scaling (RFC 1323).

Converting Mermaid diagram...

Every Segment Carries a Window It's important to note that the window field is present in every TCP segment, not just those carrying acknowledgments. However, the window field is only meaningful when the ACK flag is set. In pure data segments (ACK=0), the window field is typically ignored by the receiver. In practice, almost every TCP segment after the initial SYN has ACK=1, so almost every segment carries a meaningful window advertisement. This piggybacking makes flow control essentially free in terms of header overhead.

TCP Window Field Specifications
Property	Value	Notes
Field size	16 bits	Fixed; cannot be extended in base header
Byte position	Bytes 14-15	Immediately after flags byte
Value range	0-65535	With window scaling: 0 to 1,073,725,440
Encoding	Big-endian	Network byte order (MSB first)
Meaning when ACK=1	Receiver's available buffer	Specifies bytes sender may transmit
Meaning when ACK=0	Not meaningful	Typically ignored
Update frequency	Every ACK	Piggybacked on acknowledgments

Mathematical Semantics of the Window Value

The window value has precise mathematical semantics that govern its interpretation. Understanding these semantics is essential for correct protocol implementation. The Fundamental Meaning When a receiver sends an ACK with: Acknowledgment number = A Window = W This means: "I have received all bytes up to (but not including) A. I am willing to receive bytes with sequence numbers from A to A+W-1." The interval [A, A+W-1] is called the receive window or rwnd . Any byte with a sequence number within this interval is acceptable; bytes outside are rejected. The Right Edge The value A+W defines the right edge of the window. The sender must not send any byte with sequence number \geq A+W. This right edge is the hard limit on transmission. Relative Interpretation The window is interpreted relative to the acknowledgment number . This is crucial: the window doesn't specify an absolute sequence number range; it specifies how many bytes beyond the current acknowledgment the receiver will accept.

window_semantics.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
# TCP Window Advertisement: Mathematical Semantics
 
def interpret_window_advertisement(ack_number: int, window: int) -> dict:
    """
    Interpret the semantics of a window advertisement.
    
    The window field defines the range of acceptable sequence numbers
    relative to the acknowledgment number.
    
    Args:
        ack_number: The acknowledgment number in the TCP header
        window: The window value (possibly scaled)
    
    Returns:
        Dictionary describing the acceptable sequence number range
    """
    # Calculate the acceptable range
    left_edge = ack_number           # First acceptable sequence number
    right_edge = ack_number + window  # First UNacceptable sequence number
    
    return {
        'left_edge': left_edge,
        'right_edge': right_edge,
        'acceptable_range': f"[{left_edge}, {right_edge - 1}]",
        'num_bytes_acceptable': window,
        'interpretation': f"Receiver will accept bytes {left_edge} through {right_edge - 1}"
    }
 
 
def can_sender_transmit(seq_num: int, data_len: int, ack_number: int, window: int) -> dict:
    """
    Determine if the sender can transmit data with the given sequence number.
    
    The sender must ensure the entire segment fits within the receiver's window.
    
    Constraint: seq_num + data_len <= ack_number + window
    Also: seq_num >= ack_number (must not be already acknowledged)
    """
    right_edge = ack_number + window
    last_byte_seq = seq_num + data_len - 1  # Last byte of this segment
    
    # Check window constraints
    in_window = (seq_num >= ack_number) and (seq_num + data_len <= right_edge)
    
    return {
        'can_transmit': in_window,
        'segment_first_byte': seq_num,
        'segment_last_byte': last_byte_seq,
        'window_right_edge': right_edge,
        'reason': 'Within window' if in_window else 'Exceeds window right edge'
    }
 
 
def calculate_usable_window(
    last_byte_sent: int,
    last_byte_acked: int,
    advertised_window: int
) -> int:
    """
    Calculate the usable window—how much more the sender can transmit.
    
    The sender tracks:
    - SND.UNA: Oldest unacknowledged byte (= last_byte_acked + 1... or often used as the ack value itself)
    - SND.NXT: Next byte to send (= last_byte_sent + 1)
    - SND.WND: Current window (= advertised_window)
    
    Usable window = SND.UNA + SND.WND - SND.NXT
    
    In simpler terms:
    Usable = Window - BytesInFlight
    BytesInFlight = LastByteSent - LastByteAcked
    """
    bytes_in_flight = last_byte_sent - last_byte_acked
    usable_window = advertised_window - bytes_in_flight
    
    return max(0, usable_window)  # Cannot be negative

Sender's Interpretation From the sender's perspective, the window defines constraints on transmission: Window left edge (SND.UNA) : The oldest unacknowledged byte Window right edge (SND.UNA + SND.WND) : The maximum sequence number that may be sent Send next (SND.NXT) : The next byte the sender will transmit Usable window : SND.UNA + SND.WND - SND.NXT (space available for new transmission) The sender may transmit data with sequence numbers in the range [SND.NXT, SND.UNA + SND.WND - 1]. When SND.NXT reaches SND.UNA + SND.WND, the usable window is exhausted and the sender must wait for acknowledgments.

Converting Mermaid diagram...

Window Scaling for High-Bandwidth Networks

The original 16-bit window field can advertise a maximum of 65,535 bytes. On modern networks, this is grossly inadequate. Consider: The Bandwidth-Delay Product Problem Effective network utilization requires a window size at least equal to the bandwidth-delay product (BDP) —the amount of data that can be "in flight" on the network at any moment. BDP = Bandwidth \times Round-Trip Time Examples: 1 Gbps network, 100ms RTT: BDP = 12.5 MB 10 Gbps network, 50ms RTT: BDP = 62.5 MB 100 Gbps network, 10ms RTT: BDP = 125 MB With a maximum window of 64 KB, throughput on a 1 Gbps / 100ms network would be limited to: Throughput = Window / RTT = 65,535 bytes / 0.1 sec = 5.24 Mbps This is 0.5% of available bandwidth—a catastrophic underutilization!

RFC 1323: Window Scale Option

RFC 1323 (1992) introduced the Window Scale option to address this limitation. By negotiating a scale factor during connection establishment, TCP can use windows up to 1 GB (2^30 bytes), enabling full utilization of high-bandwidth, high-latency networks.

Window Scale Mechanism Window scaling works as follows: Negotiation : During the three-way handshake, both endpoints may include a Window Scale option in their SYN (or SYN-ACK) segments Scale factor : The option contains a single byte specifying the scale factor (0-14). The actual window size is: Advertised Window \times 2^scale_factor Mutual agreement : Both endpoints must include the option for scaling to be active. If either SYN lacks the option, no scaling is used for the entire connection Per-direction : Each direction may use a different scale factor (the SYN's scale is used for data from that sender; the SYN-ACK's scale is used for data from the other sender) Fixed for connection : Once negotiated, the scale factor cannot change during the connection lifetime

Window Scale Factor Effects
Scale Factor	Multiplier	Maximum Window	Suitable For
0	1 (2^0)	64 KB	Low bandwidth, low latency
1	2 (2^1)	128 KB	Moderate links
2	4 (2^2)	256 KB	DSL, cable modems
4	16 (2^4)	1 MB	Fast broadband
7	128 (2^7)	8 MB	Gigabit Ethernet, low latency
10	1024 (2^10)	64 MB	Gigabit, high latency (WAN)
14	16384 (2^14)	1 GB	10+ Gbps, high latency

window_scaling.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
# TCP Window Scaling: RFC 1323 Implementation
 
def calculate_effective_window(advertised_window: int, scale_factor: int) -> int:
    """
    Calculate the effective window size with scaling applied.
    
    The effective window is: advertised_window << scale_factor
    
    Args:
        advertised_window: 16-bit value from TCP header (0-65535)
        scale_factor: Negotiated scale factor (0-14)
    
    Returns:
        Effective window in bytes
    
    Maximum possible: 65535 << 14 = 1,073,725,440 bytes (≈ 1 GB)
    """
    if not 0 <= scale_factor <= 14:
        raise ValueError(f"Invalid scale factor: {scale_factor} (must be 0-14)")
    
    return advertised_window << scale_factor  # Left shift = multiply by 2^scale_factor
 
 
def recommend_scale_factor(expected_bandwidth_bps: int, expected_rtt_ms: int) -> int:
    """
    Recommend an appropriate window scale factor based on network characteristics.
    
    The window should be at least as large as the bandwidth-delay product (BDP)
    to fully utilize the network.
    
    BDP = Bandwidth × RTT
    """
    # Calculate bandwidth-delay product in bytes
    bandwidth_bytes_per_sec = expected_bandwidth_bps / 8
    rtt_seconds = expected_rtt_ms / 1000
    bdp = bandwidth_bytes_per_sec * rtt_seconds
    
    # Find minimum scale factor to support this BDP
    # We need: 65535 × 2^scale >= bdp
    # Therefore: scale >= log2(bdp / 65535)
    
    import math
    
    if bdp <= 65535:
        return 0  # No scaling needed
    
    scale_factor = math.ceil(math.log2(bdp / 65535))
    return min(scale_factor, 14)  # Cap at maximum allowed
 
 
# Examples
print("10 Gbps, 50ms RTT:", recommend_scale_factor(10_000_000_000, 50))  # ~10
print("1 Gbps, 100ms RTT:", recommend_scale_factor(1_000_000_000, 100))   # ~8
print("100 Mbps, 20ms RTT:", recommend_scale_factor(100_000_000, 20))     # ~2
print("10 Mbps, 10ms RTT:", recommend_scale_factor(10_000_000, 10))       # 0

SYN-Only Negotiation

Window scaling MUST be negotiated in the SYN exchange. It cannot be added mid-connection. If either endpoint's SYN lacks the Window Scale option, neither endpoint uses scaling for the entire connection. This explains why some legacy connections are stuck with 64 KB windows.

When and How Window Updates Are Sent

Understanding when receivers send window updates is crucial for protocol behavior and performance optimization. Piggybacked Updates The most common case: every ACK carries a window update. When the receiver acknowledges data, the window field reflects current buffer availability. No additional overhead is required—the window field is already present. Unsolicited Window Updates Sometimes the receiver's window changes significantly without new data arriving. This happens when: The application reads a large amount of buffered data Memory is allocated to the connection's buffer A zero-window situation clears In these cases, the receiver MAY send an unsolicited ACK purely to update the window. This is called a "window update." RFC 1122 Guidelines RFC 1122 specifies conditions for sending unsolicited window updates: A TCP SHOULD send a window update when the window has increased by at least: Min(one full segment, ½ RcvBuffer) This prevents the "silly window syndrome" where many small window updates provoke many small segments.

Window Update Triggers

•Data Reception: Every incoming segment triggers an ACK with current window (possibly delayed)
•Application Read: Application consuming buffered data increases available space; may trigger update
•Zero Window Clearing: When buffer was full and application reads, window update informs sender
•Buffer Resize: If buffer is dynamically resized, window update may be warranted
•Delayed ACK Timer: Timer expiry forces ACK with current window, even if no new data

Converting Mermaid diagram...

Window Update Timing Considerations The timing of window updates involves trade-offs: Too frequent : Many small updates waste bandwidth and sender CPU processing ACKs Too infrequent : Sender waits unnecessarily, reducing throughput Delayed ACKs : Standard delayed ACK (up to 200ms) may delay window updates Modern TCP implementations balance these concerns by: Piggybacking window updates on data ACKs Sending unsolicited updates only when the window increases significantly Ensuring persist probe response is immediate even if regular updates are delayed

Window Update Semantics and Edge Cases

Window updates have subtle semantics that must be handled correctly to avoid bugs and performance issues. Right Edge Preservation RFC 793 and RFC 1122 strongly recommend that the right edge of the window (ACK + Window) should never move backward. This is called "right edge preservation" or "don't shrink the window." Why? If the right edge moves backward, the sender may have already transmitted data that is now "outside" the new window. The receiver is effectively saying, "I previously accepted bytes X-Y, but now I won't accept them." This creates ambiguity: should the sender retransmit that data? Discard it? The Window Shrinking Problem

window_shrinking.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
# The Window Shrinking Problem
 
# Scenario: Sender has transmitted data based on previous window
 
# Time T1: Receiver sends ACK
ack_t1 = 1000
window_t1 = 10000
right_edge_t1 = ack_t1 + window_t1  # = 11000
 
# Sender is allowed to send bytes 1000-10999
# Sender transmits bytes 1000-5999 (6000 bytes)
 
# Time T2: Receiver's buffer pressured, sends new ACK
ack_t2 = 3000  # Acknowledges bytes 1000-2999
window_t2 = 4000  # Window shrunk!
right_edge_t2 = ack_t2 + window_t2  # = 7000
 
# Problem: Right edge moved from 11000 to 7000
# Bytes 7000-10999 were in the original window but aren't now!
 
# What about bytes 6000-7999 already sent by sender?
# They are now "outside" the receiver's claimed window
# But they were sent legitimately based on T1's window!
 
# RFC 1122 recommendation:
# Receivers SHOULD NOT shrink the right edge
# Receivers should instead wait for application to read
# before ACKing (delayed ACK helps here)
 
def is_window_shrinking(
    old_ack: int, old_window: int,
    new_ack: int, new_window: int
) -> bool:
    """
    Detect if a window update shrinks the right edge.
    
    While technically permitted by RFC 793, window shrinking
    is strongly discouraged because it creates problems for
    data already in flight.
    """
    old_right_edge = old_ack + old_window
    new_right_edge = new_ack + new_window
    
    return new_right_edge < old_right_edge

When Right Edge Retreat Happens

Right edge retreat typically occurs when the receiver is under severe memory pressure and reduces its buffer. Better implementations avoid this by: (1) Not acknowledging data faster than the buffer can reliably hold it, (2) Using delayed ACK to let application consumption catch up, (3) Maintaining buffer size commitments once advertised.

Window Update vs. Duplicate ACK A pure window update has the same acknowledgment number as the previous ACK but a different window. This must be distinguished from duplicate ACKs used for fast retransmit: Window update : Same ACK number, different window value \to Sender updates window Duplicate ACK : Same ACK number, same (or smaller) window \to Count toward fast retransmit threshold Most implementations track whether the window has changed to distinguish these cases. Zero Window: A Special Case A window of zero has special meaning: the receiver cannot accept any more data. The sender: Stops transmitting new data segments Starts a persist timer to periodically probe the receiver Must not assume the connection is dead—zero window is a normal flow control condition The receiver, when advertising zero window: Must respond to persist probes Should send a window update when space becomes available May buffer out-of-order segments if policy allows

Sender's Response to Window Advertisements

The sender maintains state and makes decisions based on received window advertisements. Understanding sender behavior completes the flow control picture. Sender State Variables The sender tracks: SND.UNA : Oldest unacknowledged sequence number SND.NXT : Next sequence number to send SND.WND : Advertised window from receiver SND.WL1 : Sequence number of last window update SND.WL2 : Acknowledgment number of last window update Updating the Send Window Not every ACK updates the window. Per RFC 793, the sender updates SND.WND only if: (SEG.SEQ > SND.WL1) OR (SEG.SEQ == SND.WL1 AND SEG.ACK > SND.WL2) This prevents stale, out-of-order ACKs from causing incorrect window updates. Calculating What to Send The sender may transmit bytes in the range [SND.NXT, SND.UNA + SND.WND - 1]. The usable window is: Usable Window = SND.UNA + SND.WND - SND.NXT When usable window > 0, the sender can transmit. When usable window = 0, the sender is window-limited and must wait.

Sender Window Processing Steps

•Receive ACK: Extract acknowledgment number and window field
•Validate sequence: Check if this ACK is acceptable (not stale)
•Update SND.UNA: Advance if ACK acknowledges new data
•Check window update validity: Compare SEG.SEQ/SEG.ACK with SND.WL1/SND.WL2
•Update SND.WND if valid: Store new window value (apply scaling if negotiated)
•Calculate usable window: Determine how much new data can be sent
•Transmit if able: Send data up to usable window limit (also limited by cwnd)

sender_window_processing.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
# TCP Sender: Window Advertisement Processing
 
class TCPSender:
    """
    Models the sender's processing of window advertisements.
    """
    
    def __init__(self, initial_seq: int):
        self.snd_una = initial_seq      # Oldest unack'd seq (send unacknowledged)
        self.snd_nxt = initial_seq      # Next seq to send
        self.snd_wnd = 0                # Current send window
        self.snd_wl1 = 0                # Seq number for last window update
        self.snd_wl2 = 0                # Ack number for last window update
        self.window_scale = 0           # Negotiated window scale factor
    
    def process_ack(self, seg_seq: int, seg_ack: int, seg_wnd: int) -> dict:
        """
        Process an incoming ACK segment and update sender state.
        
        Returns:
            Dictionary with processing results
        """
        result = {
            'ack_processed': False,
            'window_updated': False,
            'usable_window': 0
        }
        
        # Step 1: Check if ACK acknowledges new data
        if seg_ack > self.snd_una and seg_ack <= self.snd_nxt:
            self.snd_una = seg_ack
            result['ack_processed'] = True
        
        # Step 2: Check if this is a valid window update
        # RFC 793: Update window if segment is "newer" than previous update
        if self._is_valid_window_update(seg_seq, seg_ack):
            # Apply window scaling
            effective_window = seg_wnd << self.window_scale
            self.snd_wnd = effective_window
            self.snd_wl1 = seg_seq
            self.snd_wl2 = seg_ack
            result['window_updated'] = True
        
        # Step 3: Calculate usable window
        result['usable_window'] = self.get_usable_window()
        
        return result
    
    def _is_valid_window_update(self, seg_seq: int, seg_ack: int) -> bool:
        """
        RFC 793 window update validity check.
        
        A segment's window should be used to update SND.WND only if
        the segment is 'newer' than the last window update.
        """
        return (seg_seq > self.snd_wl1 or 
                (seg_seq == self.snd_wl1 and seg_ack >= self.snd_wl2))
    
    def get_usable_window(self) -> int:
        """
        Calculate how many more bytes can be transmitted.
        
        This is the flow-control-limited transmission allowance.
        Actual transmission may be further limited by congestion window.
        """
        # Right edge of window
        right_edge = self.snd_una + self.snd_wnd
        
        # Usable = right edge - next to send
        usable = right_edge - self.snd_nxt
        
        return max(0, usable)
    
    def can_send(self, data_len: int) -> bool:
        """
        Check if the sender can transmit data_len bytes.
        
        The segment must fit within the usable window.
        """
        return data_len <= self.get_usable_window()

Window Advertisement Best Practices

Decades of experience have established best practices for window advertisement that maximize throughput while avoiding pathological behavior. Receiver Best Practices

Receiver Recommendations

•Advertise accurate windows: Never advertise more space than actually available
•Avoid window shrinking: Don't move the right edge backward if possible
•Use delayed ACK wisely: Allow application time to consume data before ACKing
•Implement SWS prevention: Don't advertise tiny windows (less than MSS or ½ buffer)
•Send timely updates after zero window: Window update should be prompt when space becomes available
•Negotiate appropriate window scale: Match to expected bandwidth-delay product

Sender Best Practices

Sender Recommendations

•Respect the window: Never transmit beyond the advertised window
•Handle window updates correctly: Use RFC 793 freshness check
•Implement persist timer: Probe zero-window receivers to break deadlocks
•Combine with congestion control: Effective window = min(rwnd, cwnd)
•Avoid silly window syndrome: Don't send small segments; use Nagle's algorithm
•Handle shrinking gracefully: If right edge retreats, retransmit affected data

Common Window Advertisement Problems and Solutions
Problem	Symptom	Cause	Solution
Silly Window Syndrome	Many small segments	Small window advertisements	Clark's algorithm (receiver) + Nagle (sender)
Window stall	Transmission stops	Lost window update	Sender persist timer
Throughput limit	< bandwidth capacity	Window < BDP	Enable window scaling
Buffer overflow	Packet loss at receiver	Window too large vs. actual buffer	Accurate window reporting
Right edge retreat	Confusion about valid data	Receiver shrinks window	Avoid shrinking; handle gracefully

3 / 5

TCP Window Field Specifications

Property

Value

Notes

Field size

16 bits

Fixed; cannot be extended in base header

Byte position

Bytes 14-15

Immediately after flags byte

Value range

0-65535

With window scaling: 0 to 1,073,725,440

Encoding

Big-endian

Network byte order (MSB first)

Meaning when ACK=1

Receiver's available buffer

Specifies bytes sender may transmit

Meaning when ACK=0

Not meaningful

Typically ignored

Update frequency

Every ACK

Piggybacked on acknowledgments

# TCP Window Advertisement: Mathematical Semantics def interpret_window_advertisement(ack_number: int, window: int) -> dict: """ Interpret the semantics of a window advertisement. The window field defines the range of acceptable sequence numbers relative to the acknowledgment number. Args: ack_number: The acknowledgment number in the TCP header window: The window value (possibly scaled) Returns: Dictionary describing the acceptable sequence number range """ # Calculate the acceptable range left_edge = ack_number # First acceptable sequence number right_edge = ack_number + window # First UNacceptable sequence number return { 'left_edge': left_edge, 'right_edge': right_edge, 'acceptable_range': f"[{left_edge}, {right_edge - 1}]", 'num_bytes_acceptable': window, 'interpretation': f"Receiver will accept bytes {left_edge} through {right_edge - 1}" } def can_sender_transmit(seq_num: int, data_len: int, ack_number: int, window: int) -> dict: """ Determine if the sender can transmit data with the given sequence number. The sender must ensure the entire segment fits within the receiver's window. Constraint: seq_num + data_len <= ack_number + window Also: seq_num >= ack_number (must not be already acknowledged) """ right_edge = ack_number + window last_byte_seq = seq_num + data_len - 1 # Last byte of this segment # Check window constraints in_window = (seq_num >= ack_number) and (seq_num + data_len <= right_edge) return { 'can_transmit': in_window, 'segment_first_byte': seq_num, 'segment_last_byte': last_byte_seq, 'window_right_edge': right_edge, 'reason': 'Within window' if in_window else 'Exceeds window right edge' } def calculate_usable_window( last_byte_sent: int, last_byte_acked: int, advertised_window: int ) -> int: """ Calculate the usable window—how much more the sender can transmit. The sender tracks: - SND.UNA: Oldest unacknowledged byte (= last_byte_acked + 1... or often used as the ack value itself) - SND.NXT: Next byte to send (= last_byte_sent + 1) - SND.WND: Current window (= advertised_window) Usable window = SND.UNA + SND.WND - SND.NXT In simpler terms: Usable = Window - BytesInFlight BytesInFlight = LastByteSent - LastByteAcked """ bytes_in_flight = last_byte_sent - last_byte_acked usable_window = advertised_window - bytes_in_flight return max(0, usable_window) # Cannot be negative

Window Scale Factor Effects

Scale Factor

Multiplier

Maximum Window

Suitable For

1 (2^0)

64 KB

Low bandwidth, low latency

2 (2^1)

128 KB

Moderate links

4 (2^2)

256 KB

DSL, cable modems

16 (2^4)

1 MB

Fast broadband

128 (2^7)

8 MB

Gigabit Ethernet, low latency

1024 (2^10)

64 MB

Gigabit, high latency (WAN)

16384 (2^14)

1 GB

10+ Gbps, high latency

# TCP Window Scaling: RFC 1323 Implementation def calculate_effective_window(advertised_window: int, scale_factor: int) -> int: """ Calculate the effective window size with scaling applied. The effective window is: advertised_window << scale_factor Args: advertised_window: 16-bit value from TCP header (0-65535) scale_factor: Negotiated scale factor (0-14) Returns: Effective window in bytes Maximum possible: 65535 << 14 = 1,073,725,440 bytes (≈ 1 GB) """ if not 0 <= scale_factor <= 14: raise ValueError(f"Invalid scale factor: {scale_factor} (must be 0-14)") return advertised_window << scale_factor # Left shift = multiply by 2^scale_factor def recommend_scale_factor(expected_bandwidth_bps: int, expected_rtt_ms: int) -> int: """ Recommend an appropriate window scale factor based on network characteristics. The window should be at least as large as the bandwidth-delay product (BDP) to fully utilize the network. BDP = Bandwidth × RTT """ # Calculate bandwidth-delay product in bytes bandwidth_bytes_per_sec = expected_bandwidth_bps / 8 rtt_seconds = expected_rtt_ms / 1000 bdp = bandwidth_bytes_per_sec * rtt_seconds # Find minimum scale factor to support this BDP # We need: 65535 × 2^scale >= bdp # Therefore: scale >= log2(bdp / 65535) import math if bdp <= 65535: return 0 # No scaling needed scale_factor = math.ceil(math.log2(bdp / 65535)) return min(scale_factor, 14) # Cap at maximum allowed # Examples print("10 Gbps, 50ms RTT:", recommend_scale_factor(10_000_000_000, 50)) # ~10 print("1 Gbps, 100ms RTT:", recommend_scale_factor(1_000_000_000, 100)) # ~8 print("100 Mbps, 20ms RTT:", recommend_scale_factor(100_000_000, 20)) # ~2 print("10 Mbps, 10ms RTT:", recommend_scale_factor(10_000_000, 10)) # 0

# The Window Shrinking Problem # Scenario: Sender has transmitted data based on previous window # Time T1: Receiver sends ACK ack_t1 = 1000 window_t1 = 10000 right_edge_t1 = ack_t1 + window_t1 # = 11000 # Sender is allowed to send bytes 1000-10999 # Sender transmits bytes 1000-5999 (6000 bytes) # Time T2: Receiver's buffer pressured, sends new ACK ack_t2 = 3000 # Acknowledges bytes 1000-2999 window_t2 = 4000 # Window shrunk! right_edge_t2 = ack_t2 + window_t2 # = 7000 # Problem: Right edge moved from 11000 to 7000 # Bytes 7000-10999 were in the original window but aren't now! # What about bytes 6000-7999 already sent by sender? # They are now "outside" the receiver's claimed window # But they were sent legitimately based on T1's window! # RFC 1122 recommendation: # Receivers SHOULD NOT shrink the right edge # Receivers should instead wait for application to read # before ACKing (delayed ACK helps here) def is_window_shrinking( old_ack: int, old_window: int, new_ack: int, new_window: int ) -> bool: """ Detect if a window update shrinks the right edge. While technically permitted by RFC 793, window shrinking is strongly discouraged because it creates problems for data already in flight. """ old_right_edge = old_ack + old_window new_right_edge = new_ack + new_window return new_right_edge < old_right_edge

The sender maintains state and makes decisions based on received window advertisements. Understanding sender behavior completes the flow control picture.

Sender State Variables

The sender tracks:

SND.UNA: Oldest unacknowledged sequence number
SND.NXT: Next sequence number to send
SND.WND: Advertised window from receiver
SND.WL1: Sequence number of last window update
SND.WL2: Acknowledgment number of last window update

Updating the Send Window

Not every ACK updates the window. Per RFC 793, the sender updates SND.WND only if:

(SEG.SEQ > SND.WL1) OR 
(SEG.SEQ == SND.WL1 AND SEG.ACK > SND.WL2)

This prevents stale, out-of-order ACKs from causing incorrect window updates.

Calculating What to Send

The sender may transmit bytes in the range [SND.NXT, SND.UNA + SND.WND - 1]. The usable window is:

Usable Window = SND.UNA + SND.WND - SND.NXT

When usable window > 0, the sender can transmit. When usable window = 0, the sender is window-limited and must wait.

# TCP Sender: Window Advertisement Processing class TCPSender: """ Models the sender's processing of window advertisements. """ def __init__(self, initial_seq: int): self.snd_una = initial_seq # Oldest unack'd seq (send unacknowledged) self.snd_nxt = initial_seq # Next seq to send self.snd_wnd = 0 # Current send window self.snd_wl1 = 0 # Seq number for last window update self.snd_wl2 = 0 # Ack number for last window update self.window_scale = 0 # Negotiated window scale factor def process_ack(self, seg_seq: int, seg_ack: int, seg_wnd: int) -> dict: """ Process an incoming ACK segment and update sender state. Returns: Dictionary with processing results """ result = { 'ack_processed': False, 'window_updated': False, 'usable_window': 0 } # Step 1: Check if ACK acknowledges new data if seg_ack > self.snd_una and seg_ack <= self.snd_nxt: self.snd_una = seg_ack result['ack_processed'] = True # Step 2: Check if this is a valid window update # RFC 793: Update window if segment is "newer" than previous update if self._is_valid_window_update(seg_seq, seg_ack): # Apply window scaling effective_window = seg_wnd << self.window_scale self.snd_wnd = effective_window self.snd_wl1 = seg_seq self.snd_wl2 = seg_ack result['window_updated'] = True # Step 3: Calculate usable window result['usable_window'] = self.get_usable_window() return result def _is_valid_window_update(self, seg_seq: int, seg_ack: int) -> bool: """ RFC 793 window update validity check. A segment's window should be used to update SND.WND only if the segment is 'newer' than the last window update. """ return (seg_seq > self.snd_wl1 or (seg_seq == self.snd_wl1 and seg_ack >= self.snd_wl2)) def get_usable_window(self) -> int: """ Calculate how many more bytes can be transmitted. This is the flow-control-limited transmission allowance. Actual transmission may be further limited by congestion window. """ # Right edge of window right_edge = self.snd_una + self.snd_wnd # Usable = right edge - next to send usable = right_edge - self.snd_nxt return max(0, usable) def can_send(self, data_len: int) -> bool: """ Check if the sender can transmit data_len bytes. The segment must fit within the usable window. """ return data_len <= self.get_usable_window()

Common Window Advertisement Problems and Solutions

Problem

Symptom

Cause

Solution

Silly Window Syndrome

Many small segments

Small window advertisements

Clark's algorithm (receiver) + Nagle (sender)

Window stall

Transmission stops

Lost window update

Sender persist timer

Throughput limit

< bandwidth capacity

Window < BDP

Enable window scaling

Buffer overflow

Packet loss at receiver

Window too large vs. actual buffer

Accurate window reporting

Right edge retreat

Confusion about valid data

Receiver shrinks window

Avoid shrinking; handle gracefully

Window Advertisement

The Language of Capacity

The Window Field in the TCP Header

Mathematical Semantics of the Window Value

Window Scaling for High-Bandwidth Networks

When and How Window Updates Are Sent

Window Update Semantics and Edge Cases

Sender's Response to Window Advertisements

Window Advertisement Best Practices

There’s more to understand.

Window Advertisement

The Language of Capacity

The Window Field in the TCP Header

Mathematical Semantics of the Window Value

Window Scaling for High-Bandwidth Networks

When and How Window Updates Are Sent

Window Update Semantics and Edge Cases

Sender's Response to Window Advertisements

Window Advertisement Best Practices

There’s more to understand.