Understanding TCP receive window [closed]

Solution 1:

It does both.

The receive window is limited by available buffer space, but this isn't much of a concern with most receivers.

The other important function of the receive window is to spread out transmission in time so it's not a big burst of ten consecutive packets followed by silence until all this data is acknowledged, then another burst.

Instead, a mechanism called "TCP slow start" will gradually increase the receive window as data is transferred, so that a long-running transfer ends up with a stream of packets that are spaced roughly equally, and the acknowledge for a packet arrives just in time when the next packet at the end of the window will have to go out.

Once that flow has been established, the window further increases to allow for lost packets to be replaced without stalling.

A good flow is achieved if the window size grows linearly until the point where it reaches the amount of unacknowledged data in flight, which is the transport delay times the transfer speed.

The reason this cannot be solved with acknowledges alone is that it is rather likely for packets from a burst to be dropped on the way (dropping packets is the network's way to indicate congestion), so connection start would be a lot more stuttery before eventually converging on a steady flow.

If the receive buffer is smaller than the amount of unacknowledged data in flight, then the receive window will hit a ceiling, and the flow will be uneven, unless the receiving stack compensates for this with delayed acknowledges -- but this is an untypical scenario.

Solution 2:

1. data in flight is a general term used to refer to data that has been sent but has not yet been acknowledged. Because from the sender's standpoint this data is kinda somewhere in the network. Sender window is the amount of data that can be in flight, i.e., the amount of data that the sender can send before receiving ACK for the first segment of the window.

2. what was said in the linked post, is, I think quite poorly worded formulation on why there is a window (i.e., several packets) in flight, as opposed to only one.

try imagening what happens if you send only one packet and then wait for ACK and compare it to what happens if you send 10 packets at a time, and then wait for ACKs. It is pretty common exam task to calculate the data transfer rate. You will see, if the delay between sender and receiver is very small (e.g., they are physically near like in the same building) sending one packet at a time works fine. if the delay is somewhat significant, it is very inefficient to send data one packet at a time.

3. now, if the sender just sends packets, without regarding other participants in the network, there is high probability that these packets will get dropped and thus resources (at sender, in the network, possibly at receiver) are just wasted. For this reason, TCP's sender window is variable and depends on two mechanims: flow control and congestion control.

Flow control does what you have described. Its goal is not to overload the receiver. So, the receiver just tells the sender how much data it can accept. This is called receiver window (which is different from sender window). To be precise it is the space in the receiver buffer of the operating system. The application is incorporated indirectly here, since if the application does not take data from the receiver buffer, there will be no space freed.

Congestion control is there to ensure that the sender does not overload the network. It is a big and complicated topic. However, what is described in the other answer is congestion control and it has nothing to do with receiver window. There is a so called congestion window, which estimates (or should estimate) how much data can the network transfer without being overloaded, (i.e., dropping packets).

Sender window is the minimum of receiver window and congestion window, so that the sender does not overload either the receiver or the network.