As far as I can recall/reconstruct the only utility given by the outgoing window was so that the sender (of transfer frames) can indicate to the receiver (of transfer frames) that it will require notification of which frames have been seen by the receiver within <window size> frames, otherwise the sender will potentially block until it has received such information. As such the receiver should always be able to safely set its incoming window to be <= the sender's outgoing window, since setting it to be larger is pointless. A sender which finds itself having previously set the outgoing window size to zero, and finding its peer's incoming window size is also zero must, I think, send a flow indicating that its window size is now non-zero.
Having said that I'm not sure I ever saw much utility in this value and as such I would agree that implementations should probably just set the default outgoing window size to a large number, and ignore their peer's outgoing window when setting their own incoming window. About the only thing that we probably should be doing is ensuring that if the implied outgoing window of the peer is zero, but might open up if a flow informing the peer of the updated state, then such a flow should be sent. (Not sure I would set to MAX_INT in case anyone is trying to create an array based on the provided size upon receipt... but that's just me). -- Rob On 8 July 2015 at 20:46, Xin Chen <daron...@gmail.com> wrote: > I think one safe thing to do now is to ignore this field. I will update > service bus to not setting incoming window based on the received outgoing > window field. This is the only time we look at this value. > > > On Wed, Jul 8, 2015 at 10:58 AM, Gordon Sim <g...@redhat.com> wrote: > >> 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? >>
