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

TCP window keeps decreasing on PSH,ACKs

0

Hi,

Quick Description:
I am observing a client/server application that maintains a persistence TCP socket. When the TCP session is established, the server side sets a 64k receive window and the client sets an 8k receive window. During times of no 'big' application traffic the application appears to maintain persistence within the application by using an 11byte payload; 11bytes PSH,ACK to server, then 11bytes PSH,ACK back to client, finally zero byte ack to server. Then, this process happens again a minute later.

Question:
Why would the TCP window continue to decrease by the 11 bytes when the 11byte PSH,ACK is received? My understanding is that a PSH tells the receiver "don't buffer this". Even if that meant "only buffer this until you send an ACK", I still see the window continuously dropping.

Example:

TCP 65  35112 > 3333 [PSH, ACK] Seq=56 Ack=56 Win=7225 Len=11
TCP 65  3333 > 35112 [PSH, ACK] Seq=56 Ack=67 Win=65008 Len=11
TCP 54  35112 > 3333 [ACK] Seq=67 Ack=67 Win=7214 Len=0
TCP 65  35112 > 3333 [PSH, ACK] Seq=67 Ack=67 Win=7214 Len=11
TCP 65  3333 > 35112 [PSH, ACK] Seq=67 Ack=78 Win=64997 Len=11
TCP 54  35112 > 3333 [ACK] Seq=78 Ack=78 Win=7203 Len=0

(this happens for a ~30 minutes until the buffer returns to max and starts dropping again).

asked 21 Mar '14, 06:59

blablabla's gravatar image

blablabla
11113
accept rate: 0%

edited 21 Mar '14, 07:36


One Answer:

0

PSH does not mean "don't buffer this", it means "don't buffer this and wait for more before sending the buffer content to the applicatiuon layer". The TCP needs to put the incoming bytes somewhere before passing it on to the application, but when the push flag is set the stack is not allowed to wait for more data before it passes it on. So I guess it is normal that you have a 11 byte drop in the Window size. It should go up again in the next ACK though, but maybe the stack doesn't see the need as long as it has a lot of window bytes left for buffering more. It may be saying "I'll raise my window later, why bother now" :-)

The important thing is

a) the incoming bytes needs to be buffered to be able to pass them on; there is no direct pipeline that bypasses buffering (at least as far as I know)

b) Window size is not a problem unless it slows down the receiving of more incoming data, which in your case doesn't seem to be the problem.

answered 21 Mar '14, 10:12

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

edited 21 Mar '14, 10:13