How TCP Works - Window Scaling

In this video we will learn about how the Window Scale option in TCP works. We will see how Wireshark uses the scale factor in the handshake to create the calculated window size.
Like/Share/Subscribe for more Wireshark content!
== More Training from Chris ==
▶Getting Started with Wireshark - bit.ly/udemywireshark
▶Getting Started with Nmap - bit.ly/udemynmap
== Live Wireshark Training ==
▶TCP/IP Deep Dive Analysis with Wireshark - bit.ly/virtualwireshark
== Private Wireshark Training ==
Let's get in touch - packetpioneer.com/product/pri...

[@yunshanzhu718]

finally someone can explain it in human way

[@Joallyson]

This idea of buffer helped me alot! Thanks

[@daniel52000]

Hey Chris, thank you for explanation. I was very confuse topic for me and i got an online TCP/IP course that confused me even more, and you made it so clear and eazy to understand. thank you again.

[@alitajvidi5610]

Excellent teacher! Awesome video, thanks a lot.

[@sumanthreddymindia]

Very well explained! Awesome.

[@JDBoelter]

Nicely done!

[@ranjanadissanayaka5390]

more TCO+P and Wireshark knowledge learned.... thanks Chris.

[@sriramraghunathan6]

Wow, excellent video!

[@summeryu7604]

Hi Chris, it is very good! thanks

[@retribution1423]

Really good! Thanks :)

[@sandeshb6062]

Excellent Video . Is this the Sliding Window Technique

[@subhamthemusicalguy8851]

Fantastic video . Thanks

[@ChrisGreer]

Thanks for the comment!

[@HenriqueOrsi]

Thank you!

[@TibbyDMFLOVE]

That was really good one. Finally got someone who explained it to the point. I want to know what are the ways to calculate windows scaling factor if we missed 3-way HS. it is calculated with respect to bandwidth and RTT. So I need to know how to get these values via wireshark. Many thanks :)

[@ChrisGreer]

Hello Tibby - great question! The Window Scaling Factor is a setting set by the system TCP stack. Note that it is not based on RTT or bandwidth (maybe you are thinking congestion window?). The best way to learn the scale factor for a system when we missed it is to capture another handshake from a different connection from the same system (try to get one that is using the same application if possible) and then manually add it to the unknown one in Wireshark. You can do that under the protocol preferences for TCP. Hmmm... good idea for a video!

[@passion436]

Hi Chris, Thank you for the great posts and this resource becomes very helpful when it comes to live troubleshooting. I wanted to ask if you have these sample traces from where we can download for practice ?

[@harneetsinghharneetsingh1345]

Take captures on your own PC as it's not a big deal. If you still want them, I can help you with a few of them.

[@mitpatel4268]

Hi Chris, Thanks for the Wonderful videos. After watching the content, I have a statement which I wanted to be sure of. Could you please confirm that my understanding is correct for the below. "For a particular TCP connection, Window Size will vary dynamically. However, the Scaling Factor remains constant throughout the whole connection?"

[@ChrisGreer]

Hello Mit - Thank you for the comment! You are correct, the scale factor is constant for the life of the connection and is only exchanged in the handshake. The receive window can change and grow/shrink depending on the application and internal resources of the host.

[@bijubalan7819]

Hey Chris nice explanation as always. In your first video related to window Size, you said " Window size tells the other side how much of a data he can send to us without waiting on an acknowledgement. But here in this video, you are saying at the beginning that more window size means the someone can put more data on the wire?? My understanding is that no one can put more than 1500 bytes of MTU on the wire, if they are using Ethernet. So, is it just that an increase in window size will speed up things. Because, now the other guy can send may be 65535 bytes of data(small chunks of 1500 bytes on the wire still) without having to wait for an Ack? response is highly appreciated!

[@praveenkaliaperumal4926]

Chris, reduction of the window size on the go which means indirectly that the sliding window protocol slides over the buffer and announce the available buffer to receive the data. is that right?

[@ChrisGreer]

Hi Praveen - usually when the RX window goes down this is an indication of congestion either in the TCP stack or in the handoff to the application. It means that the application is not pulling data (or the stack is not pushing that data) out of the buffer as quickly as it is coming in. So the buffer is filling which reduces the amount of space left. The advertised window is the amount of available space.

[@zhouyou8551]

Hi Chris, thanks for sharing this great video. My question is why in your first example the window size and calculated window size are both 65535 even the window scale is 2. shouldn't it multiply by 4 - 65535*4?

[@ChrisGreer]

Hello Zhou, the scale factor is not applied to the calculated window size by Wireshark until after the SYNs in the handshake. So in the handshake it is not uncommon to see it as you described. The reason is that if both sides do not support window scaling, then we will not use the option in either direction. Thanks for the comment!

[@zhouyou8551]

@@ChrisGreer thanks for your explanation.

[@teddyzhai4442]

@@ChrisGreer Hi Chris, I was wondering the same thing while watching the video. So, a minor suggestion for clarity here would be to use a different example (after SYN in the handshake). In that case, the viewer will clearly see the effect scaling factor. Thanks

[@DikiciBurak]

Chris, i didn't understand how windows scaling and scaling factor are increasing the throughput of the data transfer between sender and the receiver. Could you enlighten me on this ? Regards.

[@sen5106]

Tks for these simple and easy to understand videos that you are making . I have watched many videos of your Wireshark series and i really like it. I have a question about this video. If we choose the scale factor wrong ,which means the scale factor does not match the real scale factor this connection had in the past, will there be any trouble for this connection ? for example : The connection between 192.168.1.1 and 10.0.0.1 had the scale factor number 2 in the past.Now we use wirehark and suddenly we catch this connection again,but in the Protocol Preferences we choose the number 4 instead of 2.

[@ChrisGreer]

Hello! Thanks for your comment. The answer is no, it will not cause any problems for the connection. Keep in mind that the connection you are analyzing has already happened. You are just analyzing something that has happened in the past. Changing the scale factor will only affect how Wireshark interprets and calculates the true window size for connections where the handshake was missed. If we choose the wrong scale factor, it will be misleading to the analyst, but it won't "break" anything. In your example, we should just see a higher calculated window size, which could hide a problem with low window size. Especially in cases where the window goes low but does not reach zero, a misconfigured scale factor could hide this problem. So we want to be sure the scale factor is correct if we manually set it. But, if we accidentally set it wrong, it won't break anything. Hope this helps!

[@shlokaandjaanvi9949]

Hi Chris, firstly thanks for this wonderful tutorial. I am a non network guy and I never had the clear understanding of TCP. Your videos has helped me a great deal to understand the TCP. I just had one question. You mentioned window scale can go upto 14, but on the server side packet you pointed it was set to 128. Can you please explain if I missed something?

[@ChrisGreer]

You are welcome! Thanks for watching.

[@lalindamadurangagamage6685]

Hi Chris, nicely explained. i have a question for you. should communicating peers have equal calculated window size in both ends?

[@harneetsinghharneetsingh1345]

It's not necessary. they can be independent and this value is not negotiated. However, it would be used if both ends support the WS.

[@arisk992]

Hello Chris! Thanks a lot for the great explanaition! I have a question : In which cases scale factor is not used? I captured this from a specific connection : [Window size scaling factor: -2 (no window scaling used)]

[@ChrisGreer]

Hey Aris, I have seen that on IoT devices lately. Where there isn't a ton of data that will be exchanged, so no need for a large receive buffer. That's where my mind would go first.

[@MrMrsstrings]

Hi Chris, Thank you for taking the time to make these videos, you are very good explaining. I have one question, though. If you could please answer that would be awesome. So the question is, why doesn't the server send the package with all the size the receiver window can accept? In this case, 65535.

[@ChrisGreer]

Hello MRN. Two reasons. 1. Because the congestion window on the server was not yet 65,535. This is the amount that the sender can send at once, and it usually starts low and goes up until it experiences congestion or packet loss. The lower number between the send and rx window is what governs throughput. 2. Depending on the network environment, sometimes the two endpoints are so close to each other that the bandwidth delay product is less than the receiver’s window. This means that the sender can send a stream of data, that data travels to the receiver, the receiver ACKS it, and those acks make it back to the sender before the sender finishes sending. That amount of outstanding data is calculated by the bandwidth delay product, and sometimes that number is less than the rx window. Hope that helps to answer the question.

[@ChrisGreer]

One other thing, sometimes a sender will pull the breaks if it cannot send one last full MSS. If the rx win is 65,535, a sender may just send 64,240 (1460 x 44 segments, assuming the MSS is 1460) and not bother sending a smaller 1,295 byte segment to fill in the last bytes of the rx win. But it just depends on the stack.

[@sasankt7068]

Hi @Chris Greer, at 3:26 i'm assuming it should be Client to server... unlike you mentioned Server to client... it caused me confusion all the way along .. so just to clarify

[@nandhakumarnnk2293]

It should be client to server

[@pbarrientos]

Hi could you say me how i'll cause a zero windows

[@mosslnnx]

Hi, Thanks for the great content, I have a diameter server, I received a lots of TCP Zero Window, I have check wireshark pcap, I see tcp.window_size_scalefactor = -1 , why it is -1 ? any idea ?

[@foshan]

Hi Chris, in your experience, what is the typical window scaling factor? The bigger the scaling factor, the larger the memory size is required on the receive side. Correct?

[@ChrisGreer]

Hey, great question. There are a bunch of factors that go into it. OS, stack, and sometimes application. For example, my machine commonly uses a scale factor of 6 (multiply by 64). So I can't say I have seen a typical one in all cases, but it is not uncommon to see a multiplier of 128, 256 or even more these days. Yes, more memory resource is required for the stack to buffer the ingress data. Which places a limit on how many connections you can support.

[@donedeal51]

What if you have a Client with a large Window Size of 256K with a scaling option of 8, on a LAN that should be able to send/receive 1Gbps, but you're noticing that the server is only sending 30 Mbps? The Servers' frame rate is 1506 MTU, and on each ack the client indicates that their receive buffer is still 256K. What else would be preventing the server from putting more data on the wire?

[@ChrisGreer]

Hi Charles, that's a great question. First on the receive window, if the client has a scale factor of 8 that would be a multiplier of 256. The advertised window is a max value of 65,535 (two bytes). So the max the client can do is 16.7MB window. On the server side, you mentioned that it is sending 30Mbps. Is that sustained throughput? There could be many reasons that it can't get past that. First - latency - on a high latency network 16.7MB receive window is filled up pretty fast. Second - Chatty app - how often does the server have to suffer the network roundtrip? Third - loss/congestion - the server could be pulling the TCP brakes because it senses loss or congestion on the wire. I would start there. Hope that helps!

[@niksvisuals]

Are there any steps to reproduce the same?

[@ChrisGreer]

Client side window issues are difficult to reproduce on-demand. It really depends on how loaded the system is and how efficiently it is using the receive buffer. When I am trying to generate this I can sometimes do it when I load up a web bowser and open up a ton of tabs and make them busy with several different things. All while doing a big file transfer of some kind. You basically have to load down the machine.

[@niksvisuals]

I'll try to load the machine and my network, and I already have a string feeling that this will work

[@RahulGupta-bn9qq]

Hi Chris - excellent stuff - would it be possible for you to create short videos on TCP Slow start , TCP Congestion Window , TCP Acceleration / optimisation , FAST Tcp.

[@ChrisGreer]

I like the ideas for content Rahul. I realize I haven't done short videos on those topics yet. Suggestion taken!

[@yevgeni10]

Can i use it on Twitch or Streaming services ?

[@sagardhiman5181]

when are you making a video on Congestion control?

[@ChrisGreer]

Hi Sagar, I cover it quite a bit in this video here - kzbin.info/www/bejne/gn_Ii42QlNSmoqs I also cover it in gory detail in my Mastering TCP with Wireshark course on Pluralsight - you can access that here - bit.ly/mastertcp

[@sagardhiman5181]

@@ChrisGreer Thanks Chris.. all your videos are super informative.. especially when you go through the traces:)

[@ChrisGreer]

@@sagardhiman5181 Thanks Sagar!

[@AndreasRiddering]

Hey Chris, do you happen to know how the scaling factor is being calculated? I found that it is derived from the buffer size value. But I just cant find out "how". Id like to know for SLES 12 for a given rwin size... Any suggestions?

[@ChrisGreer]

Hello Andreas - thanks for the comment. So either the stack or the OS itself can config the scale factor, and sometimes it is even application dependent. Depending on the OS you are using, you can usually dig around in the stack config and find where the scale factor is set and adjust it if necessary. However, don't make too large a scale factor, just because the system will need to allocate that much buffer space for every single TCP connection.

[@AndreasRiddering]

​ @Chris Greer application dependent? Okay, good to know! Would not have expected that. What I was able to find out is, that it depends on the buffer size. Somehow. I couldnt find any values for the factor itself. And you might not be 100% correct there. If the factor is lets say 4096 (2^x) the raw window size could be 1 and the resulting window size is not that big either. So the system would not need to allocate but could allocate more buffer space. To me its like with bigger factors you are able to use bigger buffers, but you don't need to. And you loose fine granularity with bigger factors. So again: any clue how to find out for lets say SLES 12, how the factor is being found?

[@ChrisGreer]

@@AndreasRiddering I would have to do some digging with that particular system, so no, off the top of my head I don't. These settings are deep in the stack settings and differ by OS.

[@AndreasRiddering]

@@ChrisGreer Thought so, that they are deep inside it ... thank you anyway.

[@clarencealbay8327]

Hi Chris. If I see quite a number of Client TCP Retransmission from a client host and I checked that the packet sent is reaching the server and the Server ACK is reaching the sending client, could it possibly mean that the Retransmission Timer of the client is small and should be increased?

[@ChrisGreer]

Is the client retransmitting before the server ack makes it back to the sending client? If so, I would check to be sure that the ack is for the same socket and that the ack numbers are truly ack-ing previously sent data. Wireshark should tag those as "Spurious Retransmissions" since they are being sent when we see a good ack. Next I would check the checksums on the acks to make sure nothing is getting corrupted on the trip back from the server.

[@clarencealbay8327]

@@ChrisGreer another thought. What is your take on cumulative ACKs and individual ACKs. When will TCP decide if it will wait for data request and ACK those requests cumulatively in a single. I think it only happens when pipelining is enabled as required in RFPs.

[@samthou7334]

Will the window size get multiplied (by window size scaling factor) everytime after a successful packet transmission?

[@ChrisGreer]

Once the window size scale factor is exchanged in the handshake, it will apply to all ensuing packets that follow for the life of the connection.

[@samthou7334]

What happens in the case of "dup acks" will it still get increased?

[@caloye86]

I have a question, I have an issue with the transfer between Client and Server (Azure) with a dedicated 1Gbps link. In this link the iRTT is around 130 ms. We can say that this value is fixed, I have seen it. My problem is that with the same Client and Server, same link, transferring the same file (.iso around 1.5BGB), some times the transfer speed is excellent, using almost all the bandwidth available around 80-100 MB/s, and some times it drops to almost 10 MB/s, of course, I can see the windows size shirking. If I switch this dedicated link to a different path with around 90 ms RTT, the transfer speed is always stable around 80 MB/s upload and download directions. If the windows size is the buffer set by the client and server or the application, How the client and server measure or take this RTT value into account to decide how windows size will shrink or increase? The transfer is done with a regular windows shared folders between the PCs. Thanks in advance.

[@caloye86]

I think you already responded to the my question in previous replies, but I think my doubt keep the same. Maybe now, I just want to redirect it to the handshake. In the handshake, RTT affect the initial window size setting?

[@thaodinh3804]

Please explain for me this. In the " TROUBLESHOOT WITH WIRESHARK-- LAURA CHAPPELL'", ON PAGE 202, said that BOTH SIDE OF A TCP CONNECTION MUST SUPPORT WINDOW SCALING IN ORDER IT TO BE USED. SO IF CLIENT HAS WINDOW SCALING OF 2 ( MULTIPLY BY 4) , SERVER HAS WINDOW SCALING OF 0( MULTIPLY BY 1) , THEN CLIENT HAS TO USE SCALING OF 0 INSTEAD OF 2. IS IT RIGHT? PLEASE HELP ME TO UNDERSTAND

[@harneetsinghharneetsingh1345]

By Support she meant that both should support it but client and server can have independent values. Having said that, 0 value by server means that it support's the window scaling but will not use window scaling. Client has nothing to with it and continue to use it with a scaling factor of 2 (multiply by 2)..

[@user-zo9ud9sr7b]

I have the same problem with the client, is anyone can tell me how to resolve this problem?

[@ChrisGreer]

You have to look into why the client is reporting a low window - usually due to a resource issue. Is it running many tasks? What is the application? Is Window Scaling enabled? Can we first enable that on the operating system? If it is enabled, what is the scale factor, can we change that? These are a few of the questions that I would ask when proceeding to troubleshoot .

[@user-zo9ud9sr7b]

​@@ChrisGreer Thanks for your answer, Chris. The client is an application one of our products running in Linux. I can't see the scale factor because there is no handshake information in the TCP packets. Maybe I should check the handshake information first. Now I suppose that the low Spec of the client caused the problem.

[@shas12able]

Can anyone explain me y is tcp windows size value is greater than MSS ?

[@shris1234]

Window size doesn't mean that much data is present in an encapsulated packet. It simply defines how much the device can receive based on the buffer space it has.

[@anudeeparkala]

How do you emulate this kind of scenarios? I'm trying to test this out in my lab but I couldn't repro it, the Window size never falls to 0, I tried FTP of 1.5 gig file. 167457 2018-01-08 19:36:09.131153 192.168.10.1 192.168.10.100 FTP-DATA 1026 "4194304" [TCP Window Full] FTP Data: 972 bytes 167458 2018-01-08 19:36:09.131245 192.168.10.100 192.168.10.1 TCP 54 "3892" 55246 → 64508 [ACK] Seq=1 Ack=124580209 Win=3892 Len=0 167459 2018-01-08 19:36:09.131256 192.168.10.100 192.168.10.1 TCP 54 "972" 55246 → 64508 [ACK] Seq=1 Ack=124583129 Win=972 Len=0 167460 2018-01-08 19:36:09.131466 192.168.10.100 192.168.10.1 TCP 54 "3072" 55246 → 64508 [ACK] Seq=1 Ack=124584101 Win=3072 Len=0

[@ChrisGreer]

Hello and thanks for the comment. I got this trace file by capturing my web browser as it downloaded a youtube video. However it was a few years ago. It sounds like the receiver in your case is well resourced on the FTP client, so the window size never falls to zero. It is able to keep up with the ingress traffic.

[@anudeeparkala]

Chris Greer thanks for the quick response and this is really very informative.. Keep them coming!

[@harshadpadgilwar4522]

Window scaling doesn't affect MTU or MSS size ?

[@ChrisGreer]

Good question Harshad, no it doesn’t. Window scaling allows us to take advantage of a much larger receive buffer for TCP. We can have an rx buffer of up to 1GB. MSS is strictly about the segments themselves and how much payload can be packed into each one.

[@davronsherbaev9133]

Why not to make window field bigger? Why so much complexity in protocol)

[@ChrisGreer]

Hi Davron - that is a great question. Basically it comes down to endpoint resource. A server or client doesn't have an unlimited amount of buffer space in memory to receive TCP data. So there needs to be a limit per connection. Every connection has allocated buffer space - and machines can support up to thousands of connections. But if the RX window is too big, that would limit the number of connections. As far as the complexity - the idea here is to keep the reliable transport mechanism at the transport layer. Not all apps use TCP, so the ones that do need a reliable method, which makes the complexity go up. UDP doesn't have all these rules, which makes it better for certain apps, but not all. Hope that helps.

[@IvanIvanov-uw6nq]

TCP was originated in RFC 793 (1981). Nobody knew at that moment 65536 bytes wouldn't be enough :)

[@epsyuma]

64k, not 65k. 1k is 1024 bytes, not 1000 bytes. Good info here. Thanks!