Subject: Impact of Receiver Window

From: "Chadi M. BARAKAT" <[email-masked]>
Date: Fri, 30 Jul 1999 14:03:41 +0200

Hello,

While simulating TCP, I found that the receiver window (rwnd) prevents
sometimes the source from sending new packets during the recovery phase.
This happens when the inflated congestion window (cwnd) exceeds rwnd.
First, this causes bursts at the end of the recovery phase which
overwhelms network buffers. Second, this causes low throughput during
Fast Recovery. Third, in case of Reno, this may prohibit the source from
correcting the second loss in a window (Reno cannot correct more than
two losses).

It is true that when cwnd = rwnd (suppose that the source has enough
data to fully utilize its window), the receiver buffer is full. But, we
know that when the retransmission is received, some places will be
emptied in this receiver. So we can follow the retransmission with some
new packets (a kind of anticipation). If these packets find places in
the buffer, our anticipation succeeds. Otherwise some packets will be
rejected and we can simply suppose at the source that these packets are
not transmitted.

Such anticipation requires to change the condition : take the minimum of
cwnd and rwnd and try to transmit new data. Why to not inflate the rwnd
along with cwnd during Fast Recovery? When a dupack is received, we
increase rwnd by one segment as we do with cwnd. When a partial ACK is
received, we deflate rwnd and set it again to the real window advertised
by the receiver. Concerning the maximum sequence number transmitted, we
set to it " snd_unack + rwnd - 1 " (of course if the actual maximum
sequence number is larger than this quantity). 

snd_unack : the highest sequence number acked.

I think that transmitting more packets that the receiver window (during
a short period) doesn't violate TCP congestion control. No more load is
injected in the network than in the case of large rwnd.

Your feedback is very welcome

Chadi

-- 
http://www.inria.fr/mistral/personnel/Chadi.Barakat

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 30 Jul 1999 09:30:47 -0400

the receiver window is used for application flow control, and not all
applications immediately consume in-sequence data..

   But, we know that when the retransmission is received, some places
   will be emptied in this receiver.

not necessarily.  if the receiving application is busy dealing with
other things and is ignoring the TCP connection for a while, the
window will just close, and no space will be freed.

Even if the app *is* almost ready to consume the in-sequence data, it
could conceivably be paged/swapped out and not actually be able to
consume it until after the beyond-the-window packet arrives and is
discarded.

   No more load is injected in the network than in the case of large
   rwnd.

Except that the receiver has only admitted having rwnd worth of
buffering; should it not be actively consuming data from the
connection, you'll just be sending packets which will be discarded by
the receiver.

					- Bill

---

From: Jamshid Mahdavi <[email-masked]>
Date: 30 Jul 1999 09:20:24 -0700

The real problem is that applications tend to unnecessarily limit rwnd
(usually by simply using the OS default values).  For a different
solution to this problem, see our autotuning research at:
	http://www.psc.edu/networking/auto.html

As others have pointed out, if the application actually meant to limit
the window, sending beyond the window is a bad idea.

--J