[BXXPwg] Flow Control again

JohnnyXia@acersoftech.com.cn JohnnyXia@acersoftech.com.cn
Tue, 25 Jul 2000 13:12:08 +0800






>I followed you well all the way to up this last bit. The window size
>can in fact be reduced - without doing what we're calling "shrinking
>the window." In fact, it may never be increased beyond zero after the
>first 4096 octet promise.

>After the first 4096 window is used up, the receiver may elect to only
>open up, say, 1024 octets. That may violate the receiver-side SWS
>avoidance policy if the receiver still has a buffer that will support
>4096 octets. But maybe the receiver shrank its buffer to conserve
>memory. If it subsequently offers up less room on its SEQ window
>extensions, that's fine. So long as it never moves that right window
>edge to the left, it's not short changing the sender and may use any
>size window it pleases.

>--
>Steven E. Harris
>Primus Knowledge Solutions, Inc.
>http://www.primus.com

Yes, I see. You are right.
First of all, "Shrinking the Window" or "Move the right edge to the left"
is
not allowed in BXXP, which is discouraged in TCP.

Second, the window size can be decreased carefully. When datas in
receiver's buffer
are retrieved by application, the buffer is available again, a SEQ message
is sent
to notify the change. If we want to shrink the buffer, this is the time.
For eg. there
are 2K data retrieved by application, and there are already 1K empty
buffer, so usually
we writes 3k in SEQ message. In order to reserve 1K data, we can only write
1+1=2K data
in SEQ message.( SWS is not considered in this example.)
In a word, if bxxp is required to shrink the buffer, a delay mechanism must
be applied.

Am I right?

Johnny Xia.