This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

expert.message == “Window update”

0
2

i have a web application running on a Windows 2008 R2 server.

is it normal to see tcp window update packet (tcp.analysis.flags as a filter) for EVERY get/post request from a client workstation on the same LAN?

Thanks

asked 10 Nov '10, 11:46

net_tech's gravatar image

net_tech
116303337
accept rate: 13%


3 Answers:

2

A packet marked "TCP Window Update" simply indicates that the sender's TCP receive buffer space has increased. Look at the previous packet from the sender - note the Window Size value in the TCP header. Then look at the "TCP Window Update" packet's Window Size setting.

What triggers these "TCP Window Update" packets? When an application picks up data from the receive buffer there is now more receive buffer space available. Wireshark sees the Window Size field value has increased and marks it to let you know the Window Size field has increased.

This is normal network behavior. Problem behaviors would be Zero Window conditions.

answered 10 Nov '10, 12:44

lchappell's gravatar image

lchappell ♦
1.2k2730
accept rate: 8%

when filtering for "expert.message == "Window is full" or tcp.analysis.zero_window" I get both (Full & Zero) packets for ALMOST every click.

Window size is at 65536 when TCP window full is captured and packet length is at 1514

(11 Nov '10, 07:18) net_tech

Wait a minute, are you saying that you get a zero window all the time? I'm not sure what you mean by "for almost every click." Are you doing an application test with "every click"? windows update msgs are normal. Constant zero window implies that the client (receiver of the data) cannot keep up, and there is a problem.

(11 Nov '10, 08:19) hansangb

Just did another test clicking through everything clickable in the app. The result is different than what I saw before.

I got 3 window full packets in less than 5 min. Is it acceptable to see some window full or I should not see them at all?

(11 Nov '10, 13:04) net_tech

It completely depends. The fact that windows are full just means that tcp can no longer send data (because the receiver's window is full). So the possibilities are:

1) the application cannot consume the data fast enough

2) The client's PC is underpowered, doesn't have the latest drivers etc.

3) You need to increase the window size beyond 64KB (see RFC 1323 or search for it on MS site.)

Of course, if it can't even keep up with 64KB of data, then increasing the window size won't really help. Are you sure the sender and receiver are seeing 64KB window size?

(11 Nov '10, 13:34) hansangb

1

This is normal. The each tier should report it's available receive buffer via the "tcp window update" - it should also vary with each update.

answered 10 Nov '10, 12:04

GeonJay's gravatar image

GeonJay
4705922
accept rate: 5%

when should the window update message been sent? What if the receiver's application retrieves only a little of data, like several bytes every time. Then there would be large amount of window update segments on the wire. Would this be a problem from efficiency perspective?

(09 Sep '13, 22:02) SteveZhou

1

Another thing to consider is how fast the recover from the window full condition is - if you see a window full condition followed immediately by a window update then the situation is likely not affecting performance. If, however, you see a window full condition that is followed by numerous window zero conditions - ouch. Download the trace files at www.wiresharkbook.com/downloads. Open up the trace file called http-download-bad.pcap and look around packet 370. That is an ugly window zero condition. Now look at http-download-good.pcap - look at packet 374 (the sender says they only have 536 bytes of receive buffer space left - this causes the sender to wait as it has more than that amount of data queued up). About 2.75 seconds later though we see a window update showing there is more space available and the data transfer resumes nicely.

When you say the "Window size is at 65536 when a TCP window full is captured and packet length is at 1514" - note that the window full packet is from someone sending data. The window full condition is Wireshark's way of indicating that the data in this packet will fill the receive window of the target for that packet. It does not mean that the sender of that 1514 byte's has a window size issue (hence the fact that they have 65535 bytes in their window size field).

answered 11 Nov '10, 16:58

lchappell's gravatar image

lchappell ♦
1.2k2730
accept rate: 8%

with time column set to Seconds since previous captured packet i get the following.
p1 0.000002 TCP Window Full (Server -> Client)
p2 0.000010 TCP Zero Windows (Client -> Server)
p3 0.002164 TCP Window Update (Client -> Server)
p4 0.001349 TCP segment of a reassembled PDU (Server -> Client)

I only get 1 window zero packet and it looks like it take 0.002164 seconds to recover. Does this mean performance is not affected?

Thanks

(15 Nov '10, 11:51) net_tech

It took less than 4 one-thousandths of a second to go from a window full condition to resuming data transfer. You're not feeling performance issues from that condition.

(15 Nov '10, 12:36) lchappell ♦

Thanks Laura.

How much time needs to pass between Zero Windows and Window update to see some effect on performance?

(15 Nov '10, 12:51) net_tech

You can't think of this problem from that perspective. If you have a million events, even a 2ms hit will add up to a huge number. If it only happens 10 times, you only wasted 20ms. However, there are other consequences like slow start etc. So depending on the stack/OS involved, there might be other hidden performance hits.

Before you get to the nitty gritty, you have to define the "chief complaint" If you go looking for "issues" any and all traces will show some artifact that can be interpreted as a "problem" So the $$$ question is, are you investigating because someone complained?

(15 Nov '10, 13:36) hansangb

Laura!

Did my question make it in to your newsletter?

http://click.icptrack.com/icp/relay.php?r=12841859&msgid=282108&act=M1O5&c=145306&destination=http%3A%2F%2Fwww.chappellseminars.com

(17 Nov '10, 12:55) net_tech

hansangb,

previously this web application ran on a physical server, but recently was moved in to a virtual environment. Since I use the app a lot on a daily bases, I noticed some performance decrease and started the investigation.

(17 Nov '10, 12:59) net_tech

Yup - it's a cool question about a little-known element - Window Updates!

(17 Nov '10, 17:50) lchappell ♦

I just don't understand why the sender would send more data than the advertised receive window size from the receiver, which caused the TCP Window Full condition on the sender.

(09 Sep '13, 22:09) SteveZhou
showing 5 of 8 show 3 more comments