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

drastic tcp window size change without scaling

0

Hopefully someone can help me understand what I'm seeing here.

  1. A client Syn goes out with a window size of 8190 and no scaling factor.
  2. Syn/ACK from server with a window size of 8192 and no scaling factor.
  3. Client piggybacks the ACK with data, but suddenly the window size is 64240.
  4. Server sends data and suddenly it's window size is 64240.

I don't understand how the window size can change so drastically when initial size is 8K and no scaling is enabled. Any insight is greatly appreciated.

No.     Time        TCPStrmDelta Source                Destination           Protocol Stream     SeQ        nSeQ       ACK        TCP Len B-flight Length Flags Window Size Info
  10528 181.247065  0.000000000  172.22.0.196          172.22.0.201          TCP      159        0                     0          0                     60     0x0002     8190        63973→443 [SYN] Seq=0 Win=8190 Len=0 MSS=1460

Frame 10528: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0 Ethernet II, Src: 92:69:13:b7:6d:b0 (92:69:13:b7:6d:b0), Dst: Vmware_98:6a:14 (00:50:56:98:6a:14) Internet Protocol Version 4, Src: 172.22.0.196 (172.22.0.196), Dst: 172.22.0.201 (172.22.0.201) Transmission Control Protocol, Src Port: 63973 (63973), Dst Port: 443 (443), Seq: 0, Len: 0 Source Port: 63973 (63973) Destination Port: 443 (443) [Stream index: 159] [TCP Segment Len: 0] Sequence number: 0 (relative sequence number) Acknowledgment number: 0 Header Length: 24 bytes …. 0000 0000 0010 = Flags: 0x002 (SYN) Window size value: 8190 [Calculated window size: 8190] Checksum: 0x2f91 [validation disabled] Urgent pointer: 0 Options: (4 bytes), Maximum segment size Maximum segment size: 1460 bytes [Timestamps]

No. Time TCPStrmDelta Source Destination Protocol Stream SeQ nSeQ ACK TCP Len B-flight Length Flags Window Size Info 10529 181.247170 0.000105000 172.22.0.201 172.22.0.196 TCP 159 0 1 0 60 0x0012 8192 443→63973 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460

Frame 10529: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0 Ethernet II, Src: Vmware_98:6a:14 (00:50:56:98:6a:14), Dst: 92:69:13:b7:6d:b0 (92:69:13:b7:6d:b0) Internet Protocol Version 4, Src: 172.22.0.201 (172.22.0.201), Dst: 172.22.0.196 (172.22.0.196) Transmission Control Protocol, Src Port: 443 (443), Dst Port: 63973 (63973), Seq: 0, Ack: 1, Len: 0 Source Port: 443 (443) Destination Port: 63973 (63973) [Stream index: 159] [TCP Segment Len: 0] Sequence number: 0 (relative sequence number) Acknowledgment number: 1 (relative ack number) Header Length: 24 bytes …. 0000 0001 0010 = Flags: 0x012 (SYN, ACK) Window size value: 8192 [Calculated window size: 8192] Checksum: 0xf8ce [validation disabled] Urgent pointer: 0 Options: (4 bytes), Maximum segment size Maximum segment size: 1460 bytes [SEQ/ACK analysis] [Timestamps]

No. Time TCPStrmDelta Source Destination Protocol Stream SeQ nSeQ ACK TCP Len B-flight Length Flags Window Size Info 10530 181.247194 0.000024000 172.22.0.196 172.22.0.201 TLSv1 159 1 113 1 112 112 166 0x0018 64240 Client Hello

Frame 10530: 166 bytes on wire (1328 bits), 166 bytes captured (1328 bits) on interface 0 Ethernet II, Src: 92:69:13:b7:6d:b0 (92:69:13:b7:6d:b0), Dst: Vmware_98:6a:14 (00:50:56:98:6a:14) Internet Protocol Version 4, Src: 172.22.0.196 (172.22.0.196), Dst: 172.22.0.201 (172.22.0.201) Transmission Control Protocol, Src Port: 63973 (63973), Dst Port: 443 (443), Seq: 1, Ack: 1, Len: 112 Source Port: 63973 (63973) Destination Port: 443 (443) [Stream index: 159] [TCP Segment Len: 112] Sequence number: 1 (relative sequence number) [Next sequence number: 113 (relative sequence number)] Acknowledgment number: 1 (relative ack number) Header Length: 20 bytes …. 0000 0001 1000 = Flags: 0x018 (PSH, ACK) Window size value: 64240 [Calculated window size: 64240] [Window size scaling factor: -2 (no window scaling used)] Checksum: 0x26cb [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis] [Timestamps] Secure Sockets Layer

No. Time TCPStrmDelta Source Destination Protocol Stream SeQ nSeQ ACK TCP Len B-flight Length Flags Window Size Info 10531 181.247636 0.000442000 172.22.0.201 172.22.0.196 TLSv1 159 1 146 113 145 145 199 0x0018 64240 Server Hello, Change Cipher Spec, Encrypted Handshake Message

Frame 10531: 199 bytes on wire (1592 bits), 199 bytes captured (1592 bits) on interface 0 Ethernet II, Src: Vmware_98:6a:14 (00:50:56:98:6a:14), Dst: 92:69:13:b7:6d:b0 (92:69:13:b7:6d:b0) Internet Protocol Version 4, Src: 172.22.0.201 (172.22.0.201), Dst: 172.22.0.196 (172.22.0.196) Transmission Control Protocol, Src Port: 443 (443), Dst Port: 63973 (63973), Seq: 1, Ack: 113, Len: 145 Source Port: 443 (443) Destination Port: 63973 (63973) [Stream index: 159] [TCP Segment Len: 145] Sequence number: 1 (relative sequence number) [Next sequence number: 146 (relative sequence number)] Acknowledgment number: 113 (relative ack number) Header Length: 20 bytes …. 0000 0001 1000 = Flags: 0x018 (PSH, ACK) Window size value: 64240 [Calculated window size: 64240] [Window size scaling factor: -2 (no window scaling used)] Checksum: 0x9dc5 [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis] [Timestamps] Secure Sockets Layer

asked 02 Oct ‘14, 09:46

dsuida's gravatar image

dsuida
466710
accept rate: 0%

edited 02 Oct ‘14, 09:50

Jasper's gravatar image

Jasper ♦♦
23.8k551284

Sorry about the formatting of the dissected packets. Looked good in the draft and then got all mushed together when I published it.

(02 Oct ‘14, 09:48) dsuida

text dumps are always hard to read. I reformatted your quote to make it a little easier, but if you can, post the trace on http://www.cloudshark.org. Use TraceWrangler (http://www.tracewrangler.com) in case you need to sanitize it first.

(02 Oct ‘14, 09:52) Jasper ♦♦
1

Use the “Code Sample” button on the selected text to format it a little better.

However, text output analysis is never fun, its much easier for folks to assist if you share an actual capture of the traffic as they can then use the tool they know best, Wireshark :-)

(02 Oct ‘14, 09:52) grahamb ♦


One Answer:

0

What you see is normal behavior. Both sides send a small window size and neither announce that they are able to use window scaling. So in the next step they both pull up their TCP window to 64k to allow the other node to send more than just a few packets in case that there is a lot of data to be transferred.

It's quite normal to see that kind of session behavior - as soon as both know that the connection is established and what the parameters are they simply adjust their window.

answered 02 Oct '14, 09:55

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Thanks. So if that is the case, what's the point in even setting an initial window size and scaling factor in the handshake if both sides end up ignoring it anyhow?

(02 Oct '14, 10:15) dsuida

It is to conserve memory for connection that are not guaranteed to be established yet. The OS/TCP stack needs to reserve as much memory for incoming bytes as promised in the window size (which is essentially just a buffer), so if you waste too much memory on connections from the start you might run out of memory.

(02 Oct '14, 14:18) Jasper ♦♦