Hi Laz,
Just to confirm, does the Window Sizing occur during the three-way handshake or after?
If it occurs during, what is the default window size? or how is this at least calculated?
Hi Rene,
Why is the maximum size of an IP packet is 65535 (16 bits). Why isnât is 32 bits for example?
Hello Joseph
As you can see in the lesson below, the window size is a parameter of the initial TCP SYN packet of the three-way handshake. This initial window size is requested by the initiator based on the capabilities of the NIC (speed, memory) and the current load on the network connection. Remember that there can be multiple TCP sessions and other network traffic on a NIC at the time of initial connection of a particular TCP session.
Once the initial window size is established, it is continually renegotiated and adjusted over the duration of the session in order to maximize efficiency of transmission.
I hope this has been helpful!
Laz
Hello again Joseph
The maximum size of an IP packet is defined based on design. IPv4 has been designed to have a maximum packet size of 65535, and the actual definition is based on the Length field found within the IPv4 packet header, which as a size of 16 bits, and is fixed. In practice however, it is quite rare, although not altogether unheard of, to use such large IP packet sizes.
I hope this has been helpful!
Laz
Hi @lagapidis
What is the difference between flow control and congestion control. Can you please explain ?
Thanks,
Hello Nihar
This is an excellent question, because these are indeed to distinct, although related mechanisms of TCP.
Flow control involves mechanisms that will ensure that a sender is not overwhelmed by a receiver that is sending packets faster than it can process. This is achieved using windowing, and acknowledgements.
Congestion control on the other hand involves mechanisms that are employed to prevent a node from overwhelming the network. This is also achieved using a mechanism associated with windowing, called slow-start, which dynamically changes the window size in a particular way.
Both involve similar mechanisms, but the first has the purpose of not overwhelming a host, while the second has the purpose of preventing congestion on the network itself. Remember that the latter can occur due to multiple hosts communicating over the same network links.
I hope this has been helpful!
Laz
When the receiver sends an acknowledgment, it will tell the sender how much data it can transmit before the receiver will send an acknowledgment.
here âitâ means receiver or sender ?
Hello Sims
Let me rewrite it this way:
When the receiver sends an acknowledgment, the receiver will tell the sender how much data the sender can transmit before the receiver will send an acknowledgment.
So the âitâ refers to the sender.
I hope this has been helpful!
Laz
Hello @ReneMolenaar & @lagapidis
If suppose Sender sends 10 segments before expecting an ACK from Receiver.
But during transit if segments 5,6,7 were unable to reach Receiver.
How will the Receiver inform to Sender to re-transmit those exact segments? And does the Receiver sends ACK for whole 10 segments only after those 3 lost segments are received/re-transmitted?
A detailed explanation will be helpful.
Thanks
Hello Tejas
In this situation, the receiver will wait until it receives all of the segments expected within the window before sending its ACK. If some segments were dropped, as you describe, the receiver will wait for a certain timeout period to see if those packets are just stragglers (sometimes segments can arrive out of order) or theyâre really lost.
Next the receiver, after the timeout, will send an ACK with the next expected byte as the ACK number. In the scenario you describe in your post, that would be an ACK with the ACK number of the first byte of segment 5, since thatâs the first segment thatâs missing.
The sender will receive this ACK, and begin sending again starting at segment 5. Any subsequent segments that may have arrived at the receiver are also resent. One other thing that may also happen is that the receiver, in the ACK sent, will propose a smaller window to alleviate the errors such as dropped segments.
I hope this has been helpful!
Laz
2 Likes
i have a doubt.
in 3way handshake the window size is being determined ?? or after 3 way handshake the sender sends 1 segment and if that gets successfully acknowledged then sender sent 2 segment at a time and if that gets successfully acknowledged then sender sent 3 segment at a time and once the sender will not get the acknowledgement of these 3 segment then it will consider the window size is 2 .
Kindly help to understand it âŚ!!
Hello Narad
During the 3 way handshake, the initial window size is agreed upon. As Rene states in the lesson, the initial window size is generally small, but every time there is a successful acknowledgement, the window size will increase. The window size will continue to increase as long as the receiver sends acknowledgements that the segments are being received successfully. So the window size is something that is dynamically adjusted during a TCP session.
The increasing or decreasing of the window size does not simply add or subtract one segment each time. The receiver, based on a particular algorithm, determines if it is able to handle a greater number of segments. If so, in its ACKs to the sender, it sends a revised window size, asking to make it bigger depending upon how it is handling the arriving segments. If it is unable to handle the flow of segments, in its next acknowledgement it will request a smaller window size. Remember, a receiver may be receiving dozens or even hundreds of TCP sessions at a time, so it must regulate each one depending upon its resources and its total bandwidth available.
I hope this has been helpful!
Laz
Guys, this lesson contains great examples. And the complementary discussion here in this forum is very rich as well!
However, I have some feedback to share.
1 - Windows scaling factor
In the previous lessons âTCP Headerâ, you explained lots of TCP fields, including the Window field. However, neither in the âTCP Headerâ lessons nor in the âTCP Window Size Scalingâ lesson you explain how âwindow scaling factorâ is used in the TCP header. You just used the âwindow scaling factorâ concept in the Wireshark examples without previously introducing it.
I guess you should explain how âwindow scaling factorâ is defined in the Options part of the TCP header before using it in the examples. Otherwise, people may get confused.
2 - Flow control (receive window) vs. congestion control
You used the term window regardless of context. You used âwindowâ when talking about TCP slow start / congestion control (cwnd), and then used âwindowâ when talking about the window field in the packets received (rwnd). I guess the way you introduced the concepts may get people confused.
My two cents are: you should split the lesson in two: (1) one just talking about the rwnd: the fact itâs a sliding window, itâs a field in TCP, goal is to avoid receiver being overload with data and not able to process it, the great Wireshark examples, etc; (2) another lesson just about cwnd, slow start, how it differs from rwnd (cwdn being related to congestion in the network - including switches and routers in the middle, and goal is to avoid senders to send more traffic than the network is capable of handle).
My experience is that rwnd and cwnd are two very important concepts in TCP/networking, and people take some time to really understand them (I include myself, it was hard to me to understand in the past). This is why I really thing you should put effort and make this particular lesson clear and easier to understand.
Hello Rarylson
Thanks for your feedback! Iâll let Rene know so he can take a look and respond to your suggestions.
Thanks again!
Laz
Is Flow Control and Windowing the same thing?
Hello Robert
Flow control refers to the ability of the sender and receiver in a TCP session to negotiate and control the flow rate of transmitted segments. Flow control is used to ensure that the receiver is not overwhelmed by receiving traffic at a rate beyond which it can handle.
Windowing is the mechanism by which flow control is achieved.
I hope this has been helpful!
Laz
1 Like
Hello Sir,
âUDP, unlike TCP is a connectionless protocol and will just keep sending traffic. There is no window size, for this reason you might want to limit your UDP traffic or you might see starvation of your TCP traffic when there is congestion.â
Referring to the above statement, how can we limit the UDP traffic ?
Regards
Rajanesh
Hello Rajanesh
You can rate limit your UDP traffic in the same way that you can rate limit any kind of traffic. This can be done using QoS mechanisms of various types including Queuing, policing, or shaping.
I hope this has been helpful!
Laz
Hello @ReneMolenaar ,
Please can you explain why the window size in the SYN,ACK is not (win=29200* ws=64 wich is 1868800) with the same way of calculation that has been done by your computer (win=65535 * ws=128 wich is 8388480).
Thanks in advance.