On 8 July 2015 at 20:13, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
> 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

I did wonder if setting it that large was too large (though its only
half the allowed value)...but decided its a bit difficult to pick a
'large enough to forget it exists, but not too large' number, and just
ensured it is configurable in case needed.

> 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?

Reply via email to