1

To perform flow control between a sender and a receiver during a TCP connection, the receiver includes in each packet to the sender, the size of available space ‘rwnd’ in its receiving buffer. This is useful to help the sender correctly throttle its transmission rate.

Considering the case where ‘rwnd=0’ and the sender has more data to send, the sender actively sends a dummy packet to test if more space is available in the receiver buffer to continue operations.

Why is an active waiting mechanism employed here, instead of having the receiver just notify the sender that its buffer is no longer full?

  • Packets get lost all the time. It is a fact of networking. – Ron Maupin Dec 23 '19 at 20:25
3

Why is an active waiting mechanism employed here, instead of having the receiver just notify the sender that its buffer is no longer full?

To prevent a deadlock.

Consider your scenario, where the receiver notifies the sender. The sender has data to send, but the receiver is still processing data and sends a rwnd=0.

Now the receiver finishes processing the data, and tells the sender that it (the receiver) is ready for more data. It sends a packet with the rwnd=x (some positive value), but the packet is lost due to some transmission or congestion error.

The sender is waiting for a nonzero rwnd value, but it never gets it. So it waits forever, deadlocking the system.

Actively polling the receiver prevents this chain of events from happening.

| improve this answer | |
  • But what if the protocol defines that the « notification » segment should be ACKed. Wouldn’t the reliable data transfer principle apply in that case? – protoneight Dec 24 '19 at 0:56
  • The receiver’s ACK isn’t ACKed, otherwise you end up forever acknowledging previous acknowledgements. But there are many ways to solve this problem. The developers picked one. – Ron Trunk Dec 24 '19 at 1:37
  • I mean when the receiver got more space in its buffer, it sends a segment to notify the sender that it is now able to accept more data. The sender needs to ACK that packet to confirm its reception. How can losses occur if we use the same mechanism of reliable data transfer that is used for other "normal" packets? – protoneight Dec 24 '19 at 14:38
  • As I said, there is more than one way to solve the problem. – Ron Trunk Dec 24 '19 at 15:49
  • That doesn’t answer my question unfortunately. I am aware that multiple ways exist to solve it, my doubts are why would the TCP designers choose the less optimized way? Having an active waiting helps in network congestion; and what if the receiving window stays full? Whereas a notification and its ack count up to 2 packets only. – protoneight Dec 25 '19 at 15:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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