On 07/08/2015 06:23 PM, Rafael Schloming wrote:
On Wed, Jul 8, 2015 at 8:58 AM, Gordon Sim <g...@redhat.com> wrote:
Under your interpretation - i.e. where the sender can change the value of
the outgoing window without ever having to inform the receiver - the
outgoing window seems to have very little value except as a hint that the
sender may be constrained by capacity limits on the number of
deliveries/transfers it is tracking. To send an outgoing window of 0 when
there have not yet even been any transfers seems to undermine even that
limited value.
I think the way to look at it under that interpretation is not that the
sender is not notifying the peer, simply that it is notifying the peer
asynchronously, and that the transfer is implicitly notifying the peer
(just like it implicitly advances the next-outgoing-id).
I'm not sure I understand. Asynchronous with respect to what? Are you
saying that a transfer implicitly expands the remote-outgoing-window
(but only if it was 0 before the transfer)?
One of the few concrete rules specified concerning the outgoing window
is that the remote-outgoing-window "MUST be decremented after every
incoming transfer frame is received, and recomputed when informed of the
remote session endpoint state". If the last information we received was
that the outgoing window was 0, what should we do on then receiving a
transfer?
