This topic is to discuss the following lesson:
Thank you for this article, I work for satellite broadband provider and i deal with high latency networks daily, i am currently troubleshooting an issue where customer is disputing his usage of 5Gig , Cisco netflow is reporting that 5Gig of Apple iOS updates, and customer has only updated his iPhone, i am planning to cap few iOS updates and your article will definitely help. I liked the way you wrote this article in sequence after TCP header and then window scaling.
Do you mind giving an option sort your articles by date posted.
I saw that you double the window size to 128000 and 256000 etc, and I know that window size filed on TCP header with size of 16 byte which mean the maximum window size = 65536 bits ( maximum IP packet size ), so how is it possible to double up over than that value ??
Good question, the window size only has 16 bits so that’s only 65535 bits. However, nowadays we use a scaling factor which allows us to use a 32 bit window size.
You can see this in the wireshark screenshots of this post:
I don’t have a post that describes how this exactly works so here’s the RFC for now, it explains it pretty well:
You are welcome, glad to hear you like it. Discussions like you have with your customer can be difficult, netflow doesn’t lie and Apple iOS updates can be pretty large. For the customer it’s just an update but they probably don’t realize that it’s a few GB. Sounds like a good idea to cap it or to warn them in time when there is a lot of traffic for a certain duration.
I’ll see if I can create a “latest post” page. I also send regular updates when I have finished some new posts.
Is this only applicable if the server and the client on the same network ? what if the client is behind a router and the server is also behind a router ? And finally how can we apply this to all traffic sourcing from a router at site A going via satellite link to a remote router at site B ? Thanks for this great article!
It doesn’t matter where the client and server are, as long as they can reach each other then you are good to go. The devices that establish the TCP connection will set the windows size so you should configure the client and server, not the router(s).
Hi, doesn’t Iperf, by default, measure the bandwidth from the client to the server? So, modifying the Window size on the server end will change how much data it is allowed to receive before sending an ack?
Hi Zhi Wei,
I’m not 100% sure how Iperf calculated bandwidth/throughput but I believe the server sends a report to the client. Changing the window size on the server will reduce the number of ACKs, increasing throughput yes.
Excellent Excellent stuff.
A dizzy Cosy question Rene.
I think Satellite communication is what normally TV channels use for live broadcast , If there a big waiting time then how the realtime applications work?
I guess this depends on your definition of “big waiting time.” Communication satellites are in geosynchronous orbit about 42,000 km above the earth. Given the speed of light, and the fact a signal must travel round trip, the minimum possible delay is about 1/4 of a second. In reality, the delay is much more than this–probably 2-3 seconds, when you factor in the path the packets must travel through networks on Earth. I am sure you have seen it on a live news program, where a news presenter asks a remote reporter in the field a question, and there is 4-5 second pause before you see an answer.
I think the answer to your question is that real-time applications (where close to real time responsiveness is required) will not use satellites. For example, stock trading applications, where even 10ths of a second matter, could not use satellites. Other applications, for which a 2-3 second delay is acceptable, have no problems.
Rene/ Andrew, I came across that CISCO can be used and iperf client and server for testing such tests? Any insight? or usable link?
You can use Iperf to test optimal window sizes yes, that’s what I did in this lesson:
Cisco VIRL allows you to add delay to interfaces so you can simulate satellite links:
I haven’t tested this before but it might be nice to try.
13 posts were merged into an existing topic: Bandwidth Delay Product
If I have understood the previous lessons on TCP correctly, it increases and decreases the window size dynamically according to network conditions. If that’s the case, what is the purpose of knowing the optimal window size for a network, given that it should figure that out dynamically?
Not sure if I have misunderstood…
This is a very good question. The initial optimal window size is calculated based on the bandwidth delay product as described in the lesson.
However, because network conditions are not static and continually change, the window size must also dynamically change to accommodate these changes. Even if the optimal window size is calculated and used, the receiver may still be overwhelmed by the amount of data that is being received during the TCP session due to additional information being sent to it on other TCP sessions for example. Or because traffic has suddenly increased on the network segment due to file transfers that have been initiated in the meantime. The result is that it may be losing information and asking repeatedly for segments to be resent. If this occurs, the receiver requests that the window size be made smaller. After several successful segment transfers the receiver may request an increase in window size to increase efficiency. This may be done and if successful, the window size is kept…
These changes can occur multiple times over the lifetime of a session, and this is why the window size must be something dynamic in order to optimise the efficiency of the transfer.
I hope this has been helpful!
On the bandwidth delay product your conversion from ms to second is not correct.
You converted 1ms to 0.01 seconds, this is not correct.
Yes you are correct, thanks for picking that up. I will let @ReneMolenaar know. Here’s the specific part that is incorrect:
The 1 ms should be 10 ms or the value in the equations should be 0.001
Thanks guys, it has been fixed.