-1

I'm currently learning about TCP, particularly the receive window aspect. I've read from several sources about it, and there's something I want to make sure I understand.

From what I've learnt, the receiver advertises a "receive window", which is - and this is where I get confused - the number of bytes that the sender is allowed to send without being acknowledged for, or in other words, the data in flight.

Now, if I try to think about it, our main goal in flow control is to make sure that the sender will not send more than the receiver can process, i.e., we want to prevent a situation in which a sender sends data that the receiver will have to discard since it won't have where to store it !

Going with this logic, I come to believe that the receive window should be corresponding to the size of the receive buffer (don't know if exactly the same, but the window size should be a derivative of the receive buffer anyhow), and the reason that we are limiting the data in flight sent by the sender is that - if the sender will send more than the window size (which, again is a derivative of the receive buffer), and the receiver hasn't acknowledged some of the data (updating the window size), there may be a situation in which the receiving end will not keep up - i.e., it will get the data faster than the application consuming it can process it, resulting in segments being discarded (hope that's clear).

But, reading this post, @DavidShwartz is saying that the aim of data in flight is NOT to avoid overfilling the buffer, rather is to handle the delay introduced by the communication channel. Which I don't quite understand.

The problem is that every source talking about this subject is not explaining the connection between the general aim of flow control and the thing with data in flight.

Can someone explain this in more detail?

3
  • Hi! Nice question, I can't give you a better explanation... may be this site is better networkengineering.stackexchange.com
    – gilito
    Nov 1, 2021 at 16:16
  • Requests for product, service, or learning material recommendations are off-topic because they attract low quality, opinionated and spam answers, and the answers become obsolete quickly. Instead, describe the business problem you are working on, the research you have done, and the steps taken so far to solve it.
    – djdomi
    Nov 1, 2021 at 16:17
  • 1
    @djdomi: not sure if this is off-topic, he's not asking for learning material but for a detail of the tcp specification.
    – digijay
    Nov 1, 2021 at 17:57

2 Answers 2

2

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.

2
  • 1) tcp slow start has nothing to do with receiver window. flow control and congestion control are two separate things. slow start increases congestion window. and sender window is set to the minimum of receiver window and congestion window. 2) congestion control will not prevent burst of packets. the way it works, it acts on receiving ACKs, so if for any reasons ACKs are aggregated, burst of packets will be send. You need a separate mechanism, called pacing for this. 3) lost packets stall, they may stall by half-rtt, but they may stall alot (e.g. tail losses).
    – Effie
    Nov 4, 2021 at 20:39
  • "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.", this statement makes no sense, because window is the amount of data in flight, or the aount of data that can be in flight.
    – Effie
    Nov 4, 2021 at 20:56
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.

  1. 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.

Not the answer you're looking for? Browse other questions tagged .