4

EDIT: I think i get it now. So a simple sliding window mechanism basically assumes the correctly received data is processed immediately. Therefore an acknowledgement implies the data was received AND processed, so the sending host can send as many new bytes as bytes beeing acknowledged.

In a real world scenario the data isn't processed immediately but rather buffered by the receiving TCP, so we need a variable sized receive window since it's indeed possible for bytes to be acknowledged but not yet processed (and therefore still in the recieving buffer).

The receiving window property in the tcp header basically tells us how much space there is left in the buffer at the time the ACK was sent, so the sender can send up to that many bytes (minus the unacknowledged bytes still in transit) to always make sure not to overflow the receiving host.

I would still really appreciate an answer if i understood this correctly.

Original Question:

i'm currently reading a book about networking and have a question regarding flow control.

As far as i understood each host has a send-buffer where byte-sequences remain that are in transit (or already received by the other host) but not yet acknowledged. And if there is still room within the buffer that is not occupied by not-yet-acknowledged-byte-sequences he can send that many bytes basically without receiving anything from the other host.

On the other hand each hosts has a receive buffer where byte-sequences remain that were correctly received but not yet read() by the upper layer.

The amount of bytes the sender is able to send without having to wait for a acknowledgement depends on how many more bytes the receiving buffer can store. This is basically what's inside the receive-window header field.

Now my question:

In the book i read (and in other ressources), the process (sliding window) was explained such that whenever the sending host receives an ACK for some bytes he can basically "move the window" and has new free space to send more data.

What i don't understand is the correlation between the ACKs and the recieve window property. I read everywhere that the sending host has to wait for another ACK if the receive window is zero (the receive buffer is full basically). But doesn't an ACK only tell me the data was received successfully opposed to "data has been read() from the receiving buffer so there is new space, you can send more bytes"?

I can't see the correlation between ACKs and the receive window property. It would make sense if the ACK is send whenever the bytes are read() from the recv buffer opposed to being received successfully, but i doubt that's the case.

Is it possible that all the packets a host sent are acknowledged but the receiving buffer is still full? This would also be kind of weird since i assumed as soon as a packet is acknowledged it's deleted from the sending buffer.

In this case there would be no correlation between the remaining free space in the send-buffer and the data the host can still send. Since the send buffer could be empty if all packets are ack'ed but the recv-buffer could be full (because the packets are received but not read() yet.

This is probably kind of a mess since i can't pinpoint my question, especially since my english skills aren't superb, but i really hope someone might be able to dissolve my confusion.

Improve this question
2
  • If you really want to understand TCP, then you should refer to the standard: RFC 793, Transmission Control Protocol. There is also the informational: RFC 1180, A TCP/IP Tutorial.
    – Ron Maupin ♦
    Mar 8, 2019 at 19:01
  • @RonMaupin Thank you very much. I read part of the standard concerning my question and i'm pretty sure i got everything right in my edit above. ACKs don't necessarily allow a sender to send more bytes. They literally are just used to acknowledge that some bytes were received correctly. It is only the receive window header-field that tells me how many more bytes i can send without any further notice from the receiver. If the upper layer doesn't read any bytes from the recv-buffer, ACKs will still be send, but with a further shrinking recv-window each time.
    –  Chinchillo
    Mar 8, 2019 at 22:59

1 Answer 1

Reset to default
4

You're close.

The receiver ACKs a segment as long as there's still space in the receive buffer. When the upper layer (=application) doesn't read the buffer or is slow doing so, the free buffer space runs out and the receive window is reduced to avoid a buffer overrun.

Simply ACKing on each receive would make the sender send more data - unless the upper layer actually reads the data, the receive buffer would overflow. So if the receiving application doesn't actually read the buffer, the receiving stack reduces the receive window size to the currently free receive buffer in order to avoid overflow.

The window size is variable and adapts to the connection variables, using a complex algorithm. Basically, the window needs to be sized by the bandwidth-delay product - this amount of data needs to be "in flight" to fully utilize the connection. Since both, effective bandwidth and round-trip time, vary during the connection, they are monitored continuously and fed back to the algorithm.

Improve this answer
3
  • 2
    Does that really make sense? If ACKs would be withheld as long as the buffer isn't read by the upper layer the sender would never know whether his segments were received correctly (which they were) or not. Timeouts would be triggered and he would keep sending the segments sicne they were received correctly, but not ACKed. I would understand if ACKs are delayed for better performance instead of being send after every received segment, but i imagine ACKs are send even without the upper layer reading from the buffer (with a potential zero recieve window value to indicate the buffer is full).
    –  Chinchillo
    Mar 8, 2019 at 15:39
  • @Chinchillo You're absolutely correct - hadn't looked into that for a while. I've edited the answer.
    – Zac67 ♦
    Mar 8, 2019 at 22:30
  • Thank you very much, the edited answer is exactly how i understood it!
    –  Chinchillo
    Mar 8, 2019 at 23:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.