7/6/22, 10:42 PM TCP Window Size Scaling

Get Full Access to our 745 Cisco Lessons Now Sign Up

Search … 

You are here: Home » Cisco » CCIE Routing & Switching Written

TCP Window Size Scaling 

Lesson Contents Course Contents

1. Wireshark Captures CCIE Routing & Switching Written

2. Conclusion
 Unit 1: Network Principles

 1.1: Network Theory

TCP (Transmission Control Protocol) is a connection oriented protocol which means that
1.1a: Differences between IOS and
we keep track of how much data has been transmitted. The sender will transmit some 
IOS XE
data and the receiver has to acknowledge it. When we don’t receive the acknowledgment
 1.1b: CEF (Cisco Express Forwarding)
in time then the sender will re-transmit the data.
 1.1d: IP Operations

 1.1e: TCP Operations

TCP uses “windowing” which means that a sender will send one or more data segments
TCP Header
and the receiver will acknowledge one or all segments. When we start a TCP connection,
TCP Window Size Scaling
the hosts will use a receive buffer where we temporarily store data before the Bandwidth Delay Product
application can process it. 1.2: Network Implementation and
Operation
When the receiver sends an acknowledgment, it will tell the sender how much data it can  1.3: Network Troubleshooting
transmit before the receiver will send an acknowledgment. We call this the window size.  Unit 2: L2 Technologies

Basically, the window size indicates the size of the receive buffer.  Unit 3: L3 Technologies

 Unit 4: VPN Technologies

Typically the TCP connection will start with a small window size and every time when  Unit 5: Infrastructure Security

there is a successful acknowledgement, the window size will increase. Here’s an  Unit 6: Infrastructure Services

example:  Unit 7: Practice Exam

Above we have two hosts, the host on the left side will send one segment and the host
on the right side will send an acknowledgment in return. Since the acknowledgement
was successful, the windows size will increase:

https://networklessons.com/cisco/ccie-routing-switching-written/tcp-window-size-scaling 1/7
7/6/22, 10:42 PM TCP Window Size Scaling

The host on the left side is now sending two segments and the host on the right side will
Get Full Access
return a single acknowledgment. Everything to our
is working fine 745 Cisco
so the Lessons
window Now
size will Sign Up
increase even further:

The host is now sending four segments and the host on the right side responds with a
single acknowledgment.

In the example above the window size keeps increasing as long as the receiver sends
acknowledgments for all our segments or when the window size hits a certain maximum
limit. When the receiver doesn’t send an acknowledgment within a certain time period
(called the round-trip time) then the window size will be reduced.

When an interface has congestion then it’s possible that IP packets are dropped. To deal
with this, TCP has a number of algorithms that deal with congestion control. One of them
is called slow start.

Congestion occurs when the interface has to transmit more data than it can

handle. It’s queue(s) will hit a limit and packets will be dropped.

With TCP slow start, the window size will initially grow exponentially (window size
doubles) but once a packet is dropped, the window size will be reduced to one segment.
It will then grow exponentially again until the window size is half of what it was when the
congestion occurred. At that moment, the window size will grow linearly instead of
exponentially.

When an interface gets congested, it’s possible that all your TCP connections will
experience TCP slow start. Packets will be dropped and then all TCP connections will
have a small window size. This is called TCP global synchronization. Here’s what it looks
like:

The orange, blue and green lines are three different TCP connections. These TCP
connections start at different times and after awhile, the interface gets congested and
packets of all TCP connections are dropped. What happens is that the window size of all

https://networklessons.com/cisco/ccie-routing-switching-written/tcp-window-size-scaling 2/7
7/6/22, 10:42 PM TCP Window Size Scaling

these TCP connections will drop to one and once the interface congestion is gone, all
Get Full Access to our 745 Cisco Lessons Now
their window sizes will increase again. Sign Up

The interface then gets congested again, the window size drops back to one and the
story repeats itself. The result of this is that we don’t use all the available bandwidth that
our interface has to offer. If you look at the dashed line you can see that we the average
interface utilization isn’t very high.

To prevent global synchronization we can use RED (Random Early Detection). this is a
feature that drops “random” packets from TCP flows based on the number of packets in
a queue and the TOS (Type of Service) marking of the packets. When packets are
dropped before a queue is full, we can avoid the global synchronization.

The end result will look similar to this:

When we use RED, our average interface utilization will improve.

Now you have an idea what the TCP window size is about, let’s take a look at a real
example of how the window size is used. We can use wireshark for this.

1. Wireshark Captures
To examine the TCP window size I will use two devices:

The device on the left side is a modern computer with a gigabit interface. On the right
side, we have a small raspberry pi which has a FastEthernet interface. The raspberry pi is
a great little device but it’s cpu / memory / ethernet interface are limited. To get an
interesting output, I will copy a large file through SSH from my computer to the
raspberry pi which will be easily overburdened.

Here’s what happened, take a look at this picture:

https://networklessons.com/cisco/ccie-routing-switching-written/tcp-window-size-scaling 3/7
7/6/22, 10:42 PM TCP Window Size Scaling

Get Full Access to our 745 Cisco Lessons Now Sign Up

In the graph above you can see the window size that was used during this connection.
The file transfer started after about 6 seconds and you can see that the window size
increased fast. It went up and down a bit but at around 30 seconds, it totally collapsed.
After a few seconds it increased again and I was able to complete the file transfer. Let’s
take a closer look at this file transfer, which starts with the three way handshake:

My fast computer uses 10.56.100.1 and the raspberry pi uses 10.56.100.164. Above you
can see that in the SYN,ACK message that the raspberry pi wants to use a window size of
29200. My computer wants to use a window size of 8388480 (win=65535 * ws=128)
which is irrelevant now since we are sending data to the raspberry pi.

After a few packets, the window size of the raspberry pi looks like this:

Above you can see that the window size has increased to 132480. Originally the window
size is a 16 bit value so the largest window size would be 65535. Nowadays we use a
scaling factor so that we can use larger window sizes.

At around the 10 second mark the window size decreased. Here’s what happened:

https://networklessons.com/cisco/ccie-routing-switching-written/tcp-window-size-scaling 4/7
7/6/22, 10:42 PM TCP Window Size Scaling

Get Full Access to our 745 Cisco Lessons Now Sign Up

The raspberry pi seems to have trouble keeping up and its receive buffer is probably full.
It tells the computer to use a window size of 26752 from now on. The computer sends 18
segments with 1460 bytes and one segment of 472 bytes (26752 bytes in total). The last
packet shows us “TCP Window Full” message. This is something that wireshark reports to
us, our computer has completely filled the receive buffer of the raspberry pi.

Once the raspberry pi has caught up a bit and around the 30 second mark, something
bad happens. Take a look at the wireshark capture below:

Above you can see that the raspberry pi sends an ACK to the computer with a window
size of 0. This means that the window size will remain at 0 for a specified amount of
time, the raspberry pi is unable to receive any more data at this moment and the TCP
transmission will be paused for awhile while the receive buffer is processed.

Here’s the actual packet:

Above you can see that the window size is now 0. Once the receive buffer has been
processed, the raspberry pi will send an ACK with a new window size:

The window size is now only 25600 bytes but will grow again. The rest of the
transmission went without any hiccups and the file transfer completed.
https://networklessons.com/cisco/ccie-routing-switching-written/tcp-window-size-scaling 5/7