Window Size and ACK Number

Question

Copy-pasting from my lecturer's slides:

• Receiver indicates the window size is 3000 
• Transfer goes ahead 
• Acknowledge every 3000 bytes 
• Receiver increases window size to 4000 
• 4000 bytes will be transferred before the next acknowledgement 

So from this I gather that the Window Size represent how many bytes the receiver will gather before sending an ACK.

But this isn't what I see in this Wireshark capture:

As you can see in the screenshot (from a TCP file transfer), the server is ACKing every ~1400 bytes or so (looking at the ACK number), but at the same time is indicating a window size of 100'000+ bytes?

From what I understand from my lecturer's slides, the server should be ACKing every 100'000+ bytes? Why is he ACKing much more often than that?

Answer 1

I teach TCP, and I often run into people who were mis-taught that the ACK is only sent when the Window Size is reached. This is not true. (To be really transparent, I too taught this incorrectly before I knew better as well, so I completely understand the mistake).

NOTE, I'll be using Receiver/Sender to describe it, but keep in mind TCP is bidirectional, and both parties maintain a Window Size.

The Window Size (that the Receiver sets) is a hard limit on how many bytes the Sender can send without being forced to stop to wait for an acknowledgement.

The Window Size does not determine how often the Receiver should be sending ACKnowledgements. Originally, the TCP protocol called for an acknowledgement to be sent after each segment was received. Later, TCP was optimized to allow the Receiver to skip ACKs and send an ACKnowledgment every other packet (or more).

The goal of TCP then, is for the Sender to continually be sending packets, without delay or interruption, because it continually receives ACKnowledgements, such that the count of "bytes in transit" is always less than the Window Size. If at any time, the Sender has sent a count of bytes equal to the window size without receiving an ACK, it is forced to pause sending and wait.

The important thing to consider in all this is the Round Trip Time. Often, when you are studying TCP in a wireshark, you are only seeing the perspective of one party in the TCP conversation, which makes it hard to infer, or truly "see", the effect of the RTT. To illustrate the effect of RTT, take a look at these two captures. They are both capturing the same conversation, a 2MB file download over HTTP, but one is from the perspective of the Client, and the other is from the perspective of the Server.

Note: its easier to analyse TCP if you turn off the Wireshark feature "Allow subdissector to reassemble TCP streams"

Notice from the Server side capture (who is the sender of the file), the Server sends 8 full sized packets in a row (packet#'s 6-13) before receiving the first ACK in packet# 14. If you drill down in that ACK, notice the Client's acknowledgement is for the segment sent in Packet#7. And the ACK the Client sent in packet 20 is from the segment sent in Packet#9.

See how the Client is indeed acknowledging every other packet. But it almost seems like it is acknowledging them "late". But in fact, this is just the effect of Round Trip Time. The Sender is able to send 7~ segments in the time it takes for the first segment to reach client and for the client's ACK to reach the server. If you take a look at the capture from the Client's perspective, it looks very 'clean', which is to say that every second packet it receives, it sends out an ACK.

Notice also what happens at Packet# 23. The Server has sent all it can, because the "bytes in transit" reaches the Window Size, so it is forced to stop sending. Until the next ACK arrives. Since the ACK's are coming in every other segment received. Each ACK allows the sender to again send two new segments, before the Window is full again, and the Server is again forced to pause. This happens up until Packet# 51, when the Client (Recever) increases the Window Size significantly, allowing the Server (sender) to start transmitting data uninhibited again... at least until Packet #175, when the new Window fills up.

Answer 2

The Window Size is used to prevent congestion at the receiver (as opposed to the congestion window that tries to prevent congestion in the network).

The functionality of it is relatively simple: the receiver informs the sender about its window size, which usually represents the available buffer size. Therefore this number should be decreased every time a new packet arrives at the receiver and should be increased each time a packet is processed at the receiver.

On the sender side, the sender tries to make sure that at any given time he/she does not have in transit more bytes than the last received advertised window and therefore lower the probability of flooding the receiver.

Now from your wireshark output we can see that your window size is relatively big and thus your transmissions are not throttled and you receive an ACK for every packet that you send (as it should be in the general case scenario where no ACK aggregation is used). Currently the mostly used maximum size for ethernet frames is 1500 bytes. If you remove all the headers you will see that the bytes that remain are actually the number by which your ACKs are increased.