TCP Window Size Scaling

Lessons Discussion
85

Hello Ali

Looking at the packet capture as seen in the lesson:

image
image1177×65 5.78 KB

Packet number 475 is a TCP SYN segment from the PC to the Raspberry with a proposed window size of win=65535 * WS=128 which is 8388480.

Packet number 476 is the response to that SYN from the Raspberry to the PC which is a SYN,ACK. In there, we have a proposed window size of win=29200 and WS=64 which is 1868800.

After a few packets are exchanged, the window size is continually renegotiated. In the very next screenshot, we see the details of packet number 639:

image
image888×464 12.9 KB

Here we see that the window size has been revised downwards to a size of win=2070 and WS=64 for a value of 132480. This renegotiation takes place based on the factors discussed in the lesson.

In every case, the window size is determined using the value of win and the scaling factor WS, specifically by multiplying those values together.

I hope this has been helpful!

Laz

1 Like
86

Hello,

Can someone please help me with this?:
“With TCP slow start, the window size will initially grow exponentially (window size doubles) but once a packet is dropped, the window size will be reduced to one segment. It will then grow exponentially again until the window size is half of what it was when the congestion occurred. At that moment, the window size will grow linearly instead of exponentially.”

But in the Wireshark capture where the graph is shown, we can see that at around the 8 second mark, the window size reached its peak, and it didn’t drop down to the value it had at around the 7 second mark, but to a lower value. Or did I misunderstand the original statement?

Thanks.
Attila.

87

Hello Attila

There are various factors that affect the window size. It’s not just “if a packet is dropped.” The type of traffic that’s being sent (bursty or smooth), the maximum throughput of the interfaces through which the traffic is routed, the congestion on the network, and the resources made available (CPU, Memory etc) on the receiver device. All of these will cause the window size to vary.

Additionally, you will notice that the graph’s sampling interval is set to one second. This means the graph is just an approximation and not an accurate millisecond-by-millisecond description of the window size. The resolution of the graph is actually very rough.

In order to see the behavior described in the quote you shared, we must be able to isolate the event of a segment drop and keep all other factors identical for the duration of the session. This is not possible, so you will never see just that behavior, but a combination of multiple factors affecting the window size.

I hope this has been helpful!

Laz

1 Like
88

Hello Laz,

Thank you again for the helpful response. :slight_smile:

I’d like to know if I understand this correctly:
“With TCP slow start, the window size will initially grow exponentially (window size doubles) but once a packet is dropped, the window size will be reduced to one segment. It will then grow exponentially again until the window size is half of what it was when the congestion occurred. At that moment, the window size will grow linearly instead of exponentially.”

Using an example, is this what happens?:
The sender starts the TCP data stream, and it keeps doubling the number of segments that it sends after every acknowledgement it receives from the receiver.

  • The sender starts by sending 1 segment in the first data stream;
  • then it sends 2^1=2 segments in the second data stream;
  • then it sends 2^2=4 segments in the third data stream. At this point, in the 3rd data stream, a packet is dropped.
  • So in the 4th data stream, the sender doesn’t send 2^3=8 segments (which would’ve happened if the 3rd data stream had been successful), or 2^2=4 segments, or 2^1=2 segments, but it sends 1 segment (just like in the 1st data stream).
  • In the next (5th) data stream, it sends twice as much as in the previous (the 4th) data stream, so it sends 2^1=2 segments.
  • At this point, the window size has reached half of what it was before the packet was dropped (because the packet was dropped when the window size reached 2^2=4 segments, and 2^1=2 is half of 4).
  • So in the 6th data stream, it sends 3 segments (because in the 5th data stream, it sent 2, and 2+1=3, so it’s a linear increase);
  • in the 7th, 4 segments;
  • in the 8th, 5 segments;
  • and so on, one integer more than in the previous data stream due to the linear nature of the window size increase.

image
image2286×412 19.5 KB

Is this correct? Or have I completely misunderstood it?

Thank you again for your continued help.
Have a nice weekend.
Attila

89

Hello Attila

Yes, that is correct! Great job!

Laz

1 Like
90

Hi Laz,

Thank you. :slight_smile: I’ve edited my original post a bit without touching the content. I’ve just added some bullet points and a chart, in case someone else might wonder about this as well. I hope this will make their learning easier.

Attila

1 Like
91

Is a relationship between jumbo frames and tcp window size ?
for example if both ends support frames > 9000B it means many tcp segments could be encapsulted in one l2 frame ?

92

Hello Juan

Remember that the TCP window size is a mechanism that operates at the Transport Layer while the Jumbo frame support feature operates at the Data Link layer. This means that there is no direct relationship between these two functionalities.

Also keep in mind that the TCP window size is not related to the size of individual segments, packets, or frames. The window size is the total number of bytes that can be sent before an acknowledgment is expected. This total number of bytes is typically sent in multiple segments, so the window size doesn’t have a direct relationship to the number of segments sent, or their size.

There is however an indirect relationship between the segment size and the size of a frame. This can be applied using what is known as the Maximum Segment Size or MSS which is negotiated at the beginning of a TCP communication, during the three-way handshake. More about the MSS can be found here:

The MSS is determined based on the maximum detected size of the underlying packet and frame sizes of the lower layers.

Now having said all of that, there is only one situation in which the window size affects the segment size: when the window size is set to something smaller than the MSS. In this case, it can limit the size of the segments that are sent, even if the MSS allows for larger segments.

By definition, it is not possible under any circumstances to have multiple segments encapsulated into a single IP packet or single frame. This is simply due to the nature of encapsulation. You can however do the opposite, that is, encapsulate a single segment into multiple IP packets, or a single IP packet into multiple frames. This is called fragmentation.

I hope this has been helpful!

Laz

1 Like
93

@lagapidis Thanks as always.
i’ve noticed i made a stupid question because besides the mtu size, the mss by default is always 1460 Bytes and you can only encapsulate 1:1 (1segment into 1 l3 packet ;1 l3 packet into 1 l2 frame).

But i know im missing something and i have many gaps in this area. For example, what’s the purpose of larger mtu frames (9000 Bytes) if it only can encapsulate one packet, and one segment. I mean, how do you take advantage of larger mtu if then the mss is 1460 ? there will be so much “empty room” into this large mtu.

94

Hello Juan

It’s good that you come to this realization, and sometimes it’s because we ask questions that we may later consider “stupid” but they’re not because they help us to come to these kinds of realizations! :sunglasses:

Now concerning your next question, this is an excellent issue to consider, and it shows your critical thinking, and you’re on the right track.

As described in a previous post, the MSS is a TCP level setting that determines the maximum amount of data that can be contained in each TCP segment. The MTU on the other hand, is a network interface layer setting that determines the maximum size of a packet that can be sent over a network link.

The purpose of larger MTU frames, such as 9000 Bytes (also known as Jumbo Frames), is to increase the efficiency of data transmission for certain types of network traffic. These larger frames mean fewer packets for a given amount of data, which reduces the overhead associated with each packet (like headers and acknowledgments) and can improve network performance.

Now, you’re correct that if the MSS is 1460 Bytes, a 9000 Byte MTU you wouldn’t be able to take advantage of this efficiency. You wouldn’t actually leave “empty room” in the sense that the frames being sent will be limited to 1500. They wouldn’t actually be 9000 bytes long with 7500 just empty. So it’s not that detrimental to the efficiency. However, TCP can automatically set the MSS to take advantage of the greater MTU sizes.

The MSS is negotiated during the TCP three-way handshake, and if the path between the sender and receiver can handle these large MTU sizes from end to end, TCP detects this and negotiates a large enough MSS that can take advantage of the capabilities of the underlying infrastructure.

However, in order for this to be successful, the full path from end to end must support large MTU sizes. If there is even one switch or router in the path that has a 1500 MTU, that MTU will be used to calculate the MSS.

Also, it’s important to note that not all network traffic consists of TCP segments that are subject to the MSS. For example, UDP traffic and ICMP messages are not subject to the MSS, so they can take full advantage of a larger MTU without any adjustments.

But remember, larger MTU sizes aren’t always better. They can cause issues with network devices that don’t support them, and they can increase the impact of packet loss. So it’s important to consider the characteristics of your specific network before deciding to use Jumbo Frames or increase the MSS. When and how it will be used will typically be part of extensive network design processes that should choose the most appropriate configuration.

I hope this has been helpful!

Laz

1 Like
95

As always, thank you for you reply. Im going back and forth between QoS lesson because this topic is a very complex one (at least for me) and there are many key factors related each other.

Now, you’re correct that if the MSS is 1460 Bytes, a 9000 Byte MTU you wouldn’t be able to take advantage of this efficiency. You wouldn’t actually leave “empty room” in the sense that the frames being sent will be limited to 1500. They wouldn’t actually be 9000 bytes long with 7500 just empty. So it’s not that detrimental to the efficiency. However, TCP can automatically set the MSS to take advantage of the greater MTU sizes.
Blockquote

Take for example HQ Video packets (>1080p res) i guess it would require larger packet size… So if we configure >9000 mtu size in all nodes and the receiver host NIC can negotiate a rcwnd of 65kB does it mean TCP will adjust the mss to fit and take advantage of these “empty room” to be filled of payload ? and now we transmit a large packet in only one l2 frame instead of several l2 frames with ip pckts fragmented ? therefore we have less overhead (for my understanding overhead , indeed is all data related to headers (ethernet, ipv4 or ipv6, udp/tcp) .

96

Hello Juan

If you have 9000 MTU set on all L2 interfaces along the path, then yes, TCP can potentially negotiate a larger MSS. You must also ensure that your IP MTU is also large enough to accommodate this. However, this is not directly related to the window size. The window size has to do with how much data can be sent before an acknowledgment is required. That amount of data can be sent in multiple segments, and indeed this is usually the case.

So if you are able to achieve an MSS of 9000 and you have a window size of 90000, then within that window size, you can send 10 segments before you need to wait for an ACK.

If you are able to achieve larger frames and packets, then yes, you get a more efficient transmission rate, with less overhead, because you’re sending more data per header. IP fragmentation will only take place if the IP packet is larger than the allowed L2 payload size. If you have both IP MTU and L2 MTU configured correctly across the path in question, you can ensure that no fragmentation takes place. Take a look at this lesson for more info (I think I shared this before, but here it is again):

Just a note on this comment, just because such video requires a larger amount of bandwidth it doesn’t necessarily create larger frames. And just to clarify, typically video services don’t use TCP at all, they prefer to use UDP, so the whole MSS feature and window size has no meaning here. This is not so important to our discussion about the MSS/MTU etc, but I just wanted to make this note for accuracy.

I hope this has been helpful!

Laz

1 Like
97

Hi Rene,
I’m a bit confused here. The window size from what i have understood is the receive buffer of the recipient. This grows exponentially and when the receive buffer is saturated and congestion takes place, TCP global synchronisation takes place where all the TCP connections will experience slow start i.e. all packets will be dropped and then all TCP connections will have a small window size.
Now my confusion is in the window size value and window size scaling factors. What are each of these? Where does the window size scaling factor reside in the header? Is this scaling factor 16bits or longer?
The image below shows the “Window” to be a 16bit value.

Could you explain the this section in more detail and in simple terms from the beginning again please? Thanks!

image

98

Hello Irfan

Let me try to clarify some of these concepts for you.

The window size is not really a buffer. Although it is sometimes called that, it can be misleading. A more appropriate description would be that the window size is the number of bytes the receiver expects to receive before sending an acknowledgment.

Not quite. The window size grows exponentially to improve the efficiency of TCP transmissions. The more bytes you send before each acknowledgment reduces the amount of overhead needed, thus improving efficiency.

Now when does slow start take place? Not when the “receive buffer” is saturated (because window size doesn’t really have a saturation point, and this is why it’s better not to think of it as a buffer). Slow start takes place whenever segments are lost. This is typically due to congestion on the network or due to the receiver not being able to handle the rate at which segments are arriving.

When the loss of a segment is detected (this is done using TCP’s SEQ and ACK numbers), slow start kicks in.

Now just a note on terminology here, when segments are lost, global synchronization does not take place. TCP slow start takes place for a that single TCP session where segment loss was detected not for all TCP sessions. The phenomenon of TCP global synchronization is something that happens when there are many TCP sessions experiencing similar packet losses due to congestion on interfaces used by multiple TCP sessions. When this occurs, they become synchronized in their slow start operations resulting in global synchronization of slow start. This is an undesirable phenomenon and that’s why Random Early Detection is used to avoid it.

Now the window scaling factor is actually found within the Options section of the TCP header. When present, it is multiplied by the number found in the 16-bit Window field to get the final window size. Details of this value can be found in RFC7323 where it is clearly defined. The result is a much larger possible window size, which results in an increase in efficiency.

I hope this has been helpful!

Laz