<div>&nbsp;&nbsp; &nbsp;I really enjoyed reading this thread -- lots of wisdom and history from what all the gurus have said. :)<br></div><div><br></div><div>&nbsp;&nbsp; &nbsp;I would add two cents with my experience of playing with the rwnd:</div><div>
<br></div><div>1. rwnd is not critical for the correctness of TCP. So, yes, we can remove rwnd without breaking TCP&#39;s correctness.</div><div><br></div><div>&nbsp;&nbsp; &nbsp;The TCP algorithm is very robust to guarantee reliability and avoid congestion. If we remove rwnd, the receiver buffer will just be viewed as part of (the last hop of) the network model in the congestion control algorithm, and receiver dropping the packet (due to lack of buffer) will be a congestion signal to the sender to slow down. This will work, though the sender now has to &quot;guess&quot; the receiver&#39;s buffer with the *same* assumption of network congestion, and the guessing function will be the same congestion control algorithm such as AIMD or whatever loss based algorithms -- not necessary sawtooth if your algorithm is not AIMD. So, removing rwnd control will be OK (maybe less efficient), and works well when the receiving application is not the bottleneck, or the receiving application has a similar processing pattern as network processing patterns.<br>
</div><div><br></div><div><br></div><div>2.&nbsp;Why do we want to remove rwnd control (John&#39;s question)? &nbsp;rwnd has its own goodness and badness:<br></div><div><br></div><div>&nbsp;&nbsp; &nbsp;Pro: rwnd control is very good in avoiding buffer overflow -- no loss will happen for lack of receiving buffer (unless OS some buffer negation).</div>
<div><br></div><div>&nbsp;&nbsp; &nbsp;Con: However, rwnd is not very good in using the buffer efficiently, esp with small buffer cases. With rwnd control, we have to allocate BDP worth of buffer at the receiver to fully utilize the network capacity. However, this BDP worth of buffer is not always necessary at all -- Think about an extreme case that&nbsp;the receiving application has a much larger processing capacity, and each packet arrives at the receiver side can be immediately consumed by the application: we only need to have 1 packet worth of buffer to hold that received packet. &nbsp;But with rwnd control, sender will only send a maximum of rwnd packets each RTT, even there is no queue-up at the receiver side at all! (As David Reed pointed out, the rwnd should indicate the receiving app&#39;s processing capacity, but unfortunately, the current way of indication is through available buffer size, which is not always an accurate indication.)</div>
<div>&nbsp;&nbsp; &nbsp;This trouble is particular obvious with the majority OS implementations of the last generation. As many research (e.g. web100) pointed out a few years ago, most of the TCP connections are bounded by a very small default buffer of Windows and also Linux. While it is easy to change the server&#39;s sending buffer, the clients&#39; receiver buffer (usually lies in millions of customers Windows boxes) is hard to change. So, if we can remove the rwnd control (e.g. having the sender ignore the rwnd and only rely on congestion control), we might improve the connection speed and don&#39;t even have extra loss if the receivers can process all the packets quickly. I remember some of the network enhancement units on the market actually do such a feature (with other features to reduce the negative effect of ignoring rwnd). This reason, however, will probably be weaken as Vista and Linux 2.6 both come with buffer auto-tuning.<br>
</div><div><br></div><div>3. rwnd is very important for the responsiveness and adaptability&nbsp;of TCP. So, no, please don&#39;t remove rwnd until you get a good solution for all TCP usages.:)<br></div><div><br></div><div>&nbsp;&nbsp; &nbsp;TCP are used almost universally in all reliability traffic. Bulk traffic where network is bottle-necked usually satisfies above conditions that receiver is not a bottleneck.&nbsp;However, there are also many cases that the receiver is slow, or the receiver&#39;s processing pattern is completely different from network router (and hence congestion control algorithm&#39;s estimation will completely go off).</div>
<div><br></div><div>&nbsp;&nbsp; &nbsp;Just give an example of networked-printer. When a networked-printer runs out of paper, it is data processing capability quickly drops to zero and lasts for minutes, then after feeding paper, its capacity quickly jumps back to normal. This on-off pattern is very different from most network congestion, and I don&#39;t see TCP congestion control algorithms can handle such case responsively. In this case, rwnd control has its own advantage: great responsiveness (by preventive control, explicit notification when the buffer opens up and etc).&nbsp;</div>
<div>&nbsp;&nbsp; &nbsp;</div><div>&nbsp;&nbsp; &nbsp;Note that to achieve such great responsiveness, rwnd control is designed to be very conservative and preventive -- sender (at this moment) can at most send data up to whatever the receiver (half RTT ago) could receive. This conservativeness guarantees that no packet will be dropped even application completely shut down its processing after announcing the rwnd. ECN and other explicit congestion control provide no such guarantee and cannot achieve the same responsiveness to a sudden capacity shutdown.</div>
<div><br></div><div>&nbsp;&nbsp; &nbsp;I think there are a lot other applications that have very different processing patterns and it is very hard to have one algorithm to predict all these patterns efficiently.</div><div><br></div><div>
<div>&nbsp;&nbsp; &nbsp;So, my understanding here is that:&nbsp;</div><div>&nbsp;&nbsp; &nbsp;A. if the receiver is very fast, we don&#39;t need rwnd control at all;&nbsp;</div><div>&nbsp;&nbsp; &nbsp;B. if the receiver&#39;s processing pattern is similar to network congestion and if tcp congestion does a good job, we don&#39;t need rwnd either.</div>
<div>&nbsp;&nbsp; &nbsp;C. The two &quot;if&quot; in A and B might stand in some cases, but not all the usage cases. I don&#39;t expect TCP will work as universally well as it&nbsp;currently does if we don&#39;t have rwnd control.<br></div></div>
<div><br></div><div><br></div><div>-David</div><div><br></div><div><br><div class="gmail_quote">On Thu, Jun 26, 2008 at 12:38 AM, Michael Scharf &lt;<a href="mailto:michael.scharf@ikr.uni-stuttgart.de">michael.scharf@ikr.uni-stuttgart.de</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
<br>
maybe this is a stupid question: Is there really a need for the TCP<br>
flow control, i. e., for signaling the receiver window back to<br>
the sender?<br>
<br>
It is well known that TCP realizes both congestion control and flow<br>
control, and that a TCP sender therefore maintains two different<br>
windows (cwnd and rwnd). Obviously, the congestion control protects<br>
the path from overload, while the flow control protects the receiver<br>
from overload.<br>
<br>
However, I have some difficulties to understand why the flow control<br>
part and receiver advertized window is actually needed.<br>
<br>
Instead of reducing rwnd, an overloaded receiver running out of buffer<br>
space could simply drop (or mark) new arriving packets, or just<br>
refrain from sending acknowledgements. As a reaction to this, the<br>
sender probably times out and the TCP congestion control significantly<br>
reduces the sending rate, which reduces the load on the receiver, too.<br>
<br>
To my understanding, a fine granular receiver advertized window is<br>
much more efficient if the buffer sizes are of the order of a few<br>
packets only. But I guess that most of today&#39;s Internet hosts have<br>
larger buffers, and therefore they hardly need a fine granular flow<br>
control.<br>
<br>
Are there reasons why TCP can&#39;t just use its congestion control to<br>
handle slow receivers? &nbsp;Do I overlook some aspect? &nbsp;Any hint or<br>
reference would be welcome.<br>
<font color="#888888"><br>
Michael<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Xiaoliang &quot;David&quot; Wei<br><a href="http://davidwei.org">http://davidwei.org</a><br>***********************************************
</div>