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

what does TCP windows scale zero means ?

0

I was analyzing a issue where I see the below TCP optiosn set , I see the server setting the windows scale to 0 , what does these mean? I have the capture on the client but not on the server.

  1. Is server not accepting the window scaling at all ? Do the server see the client receive window size as 65535 even though we offer them (65535*2^7)
  2. Is this good ? Does The server see the 65535*2^7 as the receive window advertised by us ? we are seeing 65535 constantly being advertised as the receive window size by the server.

TCP Options set by Client in SYN
TCP Options Field Value

Maximum Segment Size 1460 / TCP SACK Permitted option TRUE/ Windows Scale 7(multiply by 128)/

TCP Options set by Server in SYN+ACK
TCP Options Field Value

Maximum Segment Size 1300/ TCP SACK Permitted option Not specified in the options/ Windows Scale 0(multiply by 1)/

asked 26 Mar '11, 08:34

sreekanth's gravatar image

sreekanth
1●1●1●1
accept rate: 0%

One Answer:

2

It means that the server is RFC 1323 aware, but it's not going to go beyond what's advertised. In other words, it's not going to shift the windows field by any factor.

Almost all systems use the same SEND window space as the RECEIVE window size. So the server in question (the one that sent the syn+ack) will only send 65535 per RTT.

So if you require a bigger window size, just set it on the server.

answered 26 Mar '11, 11:29

hansangb's gravatar image

hansangb
791●2●6●19
accept rate: 12%

edited 26 Mar '11, 11:29

Thanks Hansangb ,

Ideally the client receive window should become the server send window, right? In this case if the Server is RFC 1323 aware, it should set (65535*2^7) as its send window and receive window as 65535, even if it set its window scale factor as zero.

Am I wrong anyway ?

The server is not managed by us , and the capture we have is of the client's end , I am not sure what is the receive window they are seeing as being advertised by us .

(26 Mar '11, 19:59) sreekanth

The sender will use the min() of his SENDER window or receiver's RECEIVE window. This is to ensure that the sender can guarantee delivery from his SEND buffer in case there's packet loss. Almost all systems will set the SEND window to the RECEIVE window. Some systems will let you change one or the other (AIX for example) but it's extremely rare. So assume the SEND window is the same as the RECEIVE window. Unless there are FWs in the middle that are terminating the TCP (tcp level proxy), what you see is what the other guy sent (and vice versa)

(28 Mar '11, 18:57) hansangb

My 2 cents. If the server doesn't need to allocate that extra buffer, don't force it. If the server will be sending lots of data and not receiving it then you shouldn't force the RECV window to be large. This can quickly waste memory. Consider your options and your needs carefully.

(29 Mar '11, 08:55) GeonJay

Thanks Hasangb & Geon , I sent the same observations to the owner of server , I will post any new update here.

(31 Mar '11, 20:40) sreekanth