tcp sliding window protocol

overview

the tcp sliding window protocol provides flow control and reliable data transfer by allowing multiple segments to be in flight while maintaining ordered delivery. the window slides forward as acknowledgments arrive, enabling efficient use of network bandwidth.

sliding window visualization

window variables

sender variables

receiver variables

window operation flow

window states

send window regions

1. Data sent and acknowledged (left of SND.UNA)
   - Can be discarded from send buffer
   - No longer needed for retransmission

2. Data sent but not acknowledged (SND.UNA to SND.NXT)
   - Must keep in buffer for possible retransmission
   - Waiting for ACK from receiver

3. Data not sent but ready (SND.NXT to SND.UNA + SND.WND)
   - Can be sent immediately
   - Limited by receive window

4. Data not ready to send (beyond SND.UNA + SND.WND)
   - Must wait for window to advance
   - Blocked by flow control

receive window management

1. Data received and acknowledged (left of RCV.NXT)
   - Delivered to application
   - Can be removed from buffer

2. Data expected next (at RCV.NXT)
   - Waiting for this sequence number
   - Will trigger immediate ACK

3. Data acceptable (RCV.NXT to RCV.NXT + RCV.WND)
   - Within receive window
   - Can be buffered if out of order

4. Data not acceptable (beyond RCV.NXT + RCV.WND)
   - Outside receive window
   - Will be dropped

zero window handling

window scaling

for high-bandwidth networks, the 16-bit window field (max 65,535 bytes) is insufficient. window scaling extends this:

window scale option

scaling operation

Actual Window = Window_Field_Value << Shift_Count

Example:
- Window field: 8192
- Scale factor: 7
- Actual window: 8192 << 7 = 8192 * 128 = 1,048,576 bytes (1MB)

silly window syndrome (sws)

problem

small window advertisements lead to inefficient small segments:

prevention strategies

receiver side (clark’s algorithm):

• don’t advertise small window increases
• wait until window >= min(mss, rcvbuf/2)

sender side (nagle’s algorithm):

• buffer small writes
• send only when:
  • can send full mss
  • no unacked data (all acked)
  • connection closing (fin)

window update logic

valid window update conditions

// Window update is valid if:
// 1. Segment contains new data (advances sequence)
if (SEG.SEQ > SND.WL1) {
    accept_window_update();
}
// 2. Sequence matches but ACK advances
else if (SEG.SEQ == SND.WL1 && SEG.ACK > SND.WL2) {
    accept_window_update();
}
// 3. Same sequence and ACK but window increases
else if (SEG.SEQ == SND.WL1 && SEG.ACK == SND.WL2 && SEG.WND > SND.WND) {
    accept_window_update();
}

performance implications

bandwidth-delay product

optimal window size = bandwidth × round-trip time

window sizing guidelines

1. too small - underutilizes bandwidth
2. too large - causes bufferbloat
3. optimal - keeps pipe full without queuing

implementation notes

buffer management

struct tcp_buffer {
    uint32_t base;      // SND.UNA or RCV.NXT
    uint32_t size;      // Buffer size
    uint32_t used;      // Bytes in buffer
    uint32_t window;    // Advertised window
    uint8_t* data;      // Actual buffer
};

// Send buffer regions
uint32_t acked_bytes = SND.UNA - ISS;
uint32_t unacked_bytes = SND.NXT - SND.UNA;
uint32_t usable_window = SND.UNA + SND.WND - SND.NXT;

receive buffer sizing

linux auto-tuning example:

# View current settings
sysctl net.ipv4.tcp_rmem
# min=4096 default=131072 max=6291456

# Receive buffer auto-scales between min and max
# Based on available memory and connection needs

common issues

window stalls

symptoms:

• zero window persists
• throughput drops to zero
• connection appears hung

causes:

• application not reading data
• insufficient receive buffer
• memory pressure

solutions:

• increase socket buffer sizes
• improve application read performance
• monitor buffer utilization

window scaling problems

symptoms:

• throughput limited despite bandwidth
• cannot achieve expected speeds
• works locally, fails over wan

causes:

• middlebox interference
• firewall stripping options
• window scale not negotiated

debugging:

# Check if window scaling enabled
ss -tin | grep -i scale

# Verify window scale in packet capture
tcpdump -i any -nn 'tcp[tcpflags] & tcp-syn != 0'

key takeaways

• sliding window enables efficient, reliable data transfer
• window size determines maximum data in flight
• flow control prevents receiver overflow
• window scaling necessary for high-bandwidth paths
• proper sizing critical for performance
• zero window requires special handling

references

• rfc 793 - original tcp specification
• rfc 9293 - tcp specification (current)
• rfc 7323 - tcp extensions (window scaling)
• rfc 813 - window and acknowledgment strategy

next steps

• explore tcp fundamentals for core concepts
• study congestion control
• understand congestion control algorithms