Hello All I am new to Wireshark, and was watching one of Laura Chappell excellent videos (I love those videos), where she mentioned intermediate devices (router, etc) can mess with your TCP header, for example 'Window Size Scaling Factor' So if Computer A says I have a 'Window Size' of 256 and by the way I can sale this by 256 (e.g. the Window Scaling Factor) meaning I can actually support a Window Size of 65536, but the router amends the Window Scaling Factor (or nulls it) so it is effectively 1; Meaning Computer B hears the message I can support Window Size of 256 x 1 = 256 (e.g. very bad for performance). I have two questions about this please. 1: Why does Computer A not just say at I can support of Window Size of 65536 with a scaling factor of 1 in the first place? Therefore if the router a nulls the scaling factor it does not matter as you still tell the other party you can support 65536. 2: Why does the router mess this this in the first place? I can understand the router needs to consider the maximum MTU (Ethernet Frame Size, I believe this refers to), and possible the segment size (IP data) but the Window Size as far as I am aware is just the receiver telling the sender I can receive this many segments (collection of bytes) before I need to send you an ACK. Therefore I cannot see what the Window Size and therefore the Window Scaling Factor has to do with the router in the path; and therefore why the router would want to mess with it. Thanks All in advance EBrant asked 23 Oct '16, 00:36  EBrant edited 23 Oct '16, 22:46  Jaap ♦ |
2 Answers:
The basic field of the TCP header carrying the window size is just two bytes in size, so the maximum window size it can express is 65535. The purpose of introduction of the window size scaling mechanism was to extend the range that can be expressed using those two bytes (for the price of losing resolution which is negligible compared to the benefits). If your example of value 256 and scaling factor 256 is a real life one, not just illustrative, it would really be possible not to use the scaling factor at all and state the window size of 65535 using the two bytes. But you would have to ask the authors of the TCP stack implementation on ComputerA why they did it the former way. Wireshark can only show you what has happened; if you want to know why that happened, you need to see RFCs and/or ITU recommendations and the source codes of the protocol stacks and applications.
There may be several reasons:
answered 23 Oct '16, 01:00  sindy edited 23 Oct '16, 01:11 |
Hm, the behavior might become clear, if we look at the TCP handshake. First a few words on Window Scaling: This is nowadays supported by virtually all recent TCP stacks. Both, client and sender, send an aptly named TCP option with the SYN flag. The scale option will be translated to a power of 2. So Windows Scaling 8 will translate to a factor of 2^8 = 256. The TCP window size is a 16 bit field, which limits the window size to 2^16-1 bytes. With a scale factor of 8 this connection could now use 2^(16+8)-1 bytes. This is especially nice for "long fat networks" (LFN, some times called "elefant"). If one side signales a scale factor of 0 that translates to "hey, you other guy signal a really large receive window which I will use. But me, I stay with a limit of 2^16-1 Byte" Selecting an initial Window Size If your systems selects a window size of 256 with a scale factor of 8 (= multiply by 256) the window size can be expanded way beyond 64 kByte. This allows a much greater throughput, if the connection uses requires it. Hint: A Gigabit link with a 1 millisecond RTT easily runs well with a 125 kByte window. A scale factor of 1 would prevent the connection from using the full throughput. Routers messing with the hand shake In certain situations a device in the network will mess up the hand shake. Possible perpetrators are WAN-optimizers, faulty or misconfigured load balancers, routers or firewalls with a silly NAT algorithms or another configuration problem. One such culprit could be a firewall or router manufactured by Cisco that uses a feature called "TCP normalization". Assume the following network: Say, Node-A sends a packet with a Window Size 64 kByte and scale factor 0. Router-B passes the Window Scaling option from the TCP header incoming packets and forwards the packet to Node-B. Node-B responds with a scale factor of 8 and a Window Size of 256, which would translate to 64 kB. Trouble starts, if this outbound packet is modified by any router / load-balancer / optimizing magic device and the scaling option is removed: Node A assumes that Window Scaling is disabled for this connection, as the SYN-ACK did not include a Scale-Option. As Node B assumes that we have Window Scaling and signals a very small number as window size, the connection will slow down to a crawl. Good hunting answered 23 Oct '16, 06:28  packethunter 1 Actually, Window Scaling can increase the senders transmit window to 1 GByte, if the scale factor 14 is used: The window size would be expanded by 14, i. e. multiplied by 2^14 = 8192. 2^30 = 1 GByte The window size signals, how much data the other end may transmit, without waiting for an acknowledgement. The window size may grow or shrink, depending on the current load of the receiver. Say, you upload up a large file to an FTP server. If the server starts the conversation with a window size of 64 kByte the client can send so many bytes without waiting for an acknowledgement. If the server wants to slow the client, because the disk is slow, CPU is busy or any other reason, the server can shrink the window size. In the worst of all cases the window size goes down to 0, which would be like "hold your data for a moment, I need to process what to you send me so far". The window size usually goes up within a few milliseconds. The server can increase the window size (with window scaling beyond 64 kB). This tells the client "keep it coming, I can keep up with you". A good description of the window size is given by Jeremy Stretch on his web site packetlife.net. If one side starts the conversation with a window size of 256 and a scale factor of 8 the initial window would be 64 kByte. Still, the window size can increase to 65535 * 256 = 16 MByte. The other end may or may not use the window size. This largely depends on the application. For example, FTP would benefit from a large window. SMB is delivering smaller data chunks and might not benefit from a large window size. (23 Oct '16, 10:59) packethunter Thanks very much again Sindy and PacketHunter fro your detailed replies, its nice to know there are people out there that will really help you out. Next I will buy some books (it's going to take a while but I am determined to learn this well). EBrant :) (23 Oct '16, 21:40) EBrant |
Hello PacketHunter and Sindy, thanks for both taking the time to explain. this has really helped to clear things up.
So if I have understand you both in a nutshell Windows Size is a two byte (16 bit fieled) meaning a maximum of 65535 -1 = 65534 (64k)
however the scaling factor option (e.g. use one of the previously free options flags so do how have to re-engineer, or possible the options flag was always there) means you can scale up to 16MB Window Size. Is that correct so far please?
Also, from what I understand from above, if I send a SYN with a small Windows size (256) and a scale factor of 8 (meaning my window can scale to 64k) the receiver who is about the send a SYN-ACK thinks OK this guy can do Windows scaling and therefore I will 'also' send a smallish window size with a scale option set (e.g. reply in a similar manor) rather than sending say a window size of say 64k with no scaling option set in my SYN-ACK.
Is the above correct/reasonable assumption so far please?
Then looking at the interconnected device (router/firewall etc), if it has low RAM, slowish CPU etc. but wants to inspect the packets (for filtering or whatever reason) is it correct to say/assume the router/firewall "likes a smaller window size" as it knows that when the number of packets have been sent by the client up to the window size the client will then wait for a ACK from the other side for these packets (segment/s) it sent, giving the router that split second of time to inspect/filter/amend the packet etc before passing them on.
is my assumption above correct please?
Thanks again EBrant
Mostly.
16 MB is the maximum window size for a scaling factor of 8, but the scaling factor may be higher.
No. If you send a small window size (256) and a scale factor of 8, it means the current size of your receive window is 65536 bytes. The maximum size is 65535×256, i.e. about 16 MBytes.
There is no rule that the window size scaling factor must be the same in both directions. However, the presence of the window size scaling factor option in the
SYN,ACKpacket of the server, regardless the scaling factor value, confirms to the client that the server supports window size scaling. If the client sends the window scaling factor option in itsSYNpacket but doesn't receive one from the server, it must use a scaling factor of 0. Similarly, if there is no window scaling factor option in theSYNpacket from the client, the server knows there is no point in using a scaling factor as the client doesn't support it, so it doesn't send that option in itsSYN,ACKpacket.If processing time would be a concern, it wouldn't be enough to rely on smaller window size and the router would have to take active measures, i.e. not to forward the packets until it analyses them.