On Wed, Jul 8, 2015 at 8:58 AM, Gordon Sim <g...@redhat.com> wrote: > On 07/08/2015 03:49 PM, Rafael Schloming wrote: > >> I think what is confusing about the spec language is that it is defining >> the meaning of the value in terms of the sending endpoint's state and then >> not saying anything about when the sending endpoint is obligated to >> communicate the value to the receiver. This is because (at least as >> originally conceived) it is never directly obligated to communicate the >> value to the receiver, i.e. it could just choose to grow its array >> indefinitely. >> >> By contrast the incoming-window is defined in terms of the receiver's >> endpoint state and it is (relatively) clearly communicated that the >> receiver is obligated to communicate a non-zero incoming-window if it >> wishes to receive transfer frames. >> >> So while I agree that the language as defined requires the outgoing window >> to be increased from zero, I don't think this implies (at least without a >> more careful reading) that the sender needs to communicate this fact >> before >> sending transfers. It owns the value so it can effectively increase the >> outgoing-window to 1 momentarily, send the transfer, and then decrease it >> back to zero without needing to sandwich that transfer in flow frames in >> order to signal the changing window values. >> > > I think that is a bit of a stretch given the language the spec does use. I > agree it doesn't explicitly state the rule in those terms, however it does > say: > > The remote-outgoing-window reflects the maximum number of > incoming transfers that MAY arrive without exceeding the > remote endpoint’s outgoing-window. This value MUST be > decremented after every incoming transfer frame is received, > and recomputed when informed of the remote session endpoint > state. > > I.e. the language suggests that a compliant receiver must do some work to > keep track of the value and states that this value is tied to the maximum > number of transfers that may arrive. > > Put another way, the rule that says it is illegal for the sender to send >> transfers when the receiver's incoming window is zero creates an >> obligation >> for the receiver to communicate its window, but there is no corresponding >> rule for the receiver, e.g. nothing says it is illegal for the receiver to >> send credit when the sender's outgoing-window is zero, nor that the >> receiver must compute it's incoming-window based on the sender's >> outgoing-window, >> > > I certainly agree that nothing ties the receivers incoming window to the > senders outgoing window in any fixed way. > > so there is no obligation similarly implied for the sender. >> > > I disagree here. I think the fact that begin and flow have the > outgoing-window field defined as mandatory, and the fact that there is > specific (though bewildering) language that appears to mandate the tracking > of the senders outgoing window by the receiver, *implies* (though does not > explicitly spell out) that the sender is supposed to keep the receiver > informed of its outgoing window. > > Further I think the sender should not take the lack of credit as grounds >>> to set a window of 0. The receiver knows it has not issued credit. (At >>> the >>> link level, the sender can also indicate that it has messages awaiting >>> link >>> credit). >>> >>> >> I agree that we shouldn't do this in our implementation, however I think >> it >> is a valid interpretation, >> > > The flow frame describes the outgoing window field as defining: > > the maximum number of outgoing transfer frames that the > endpoint could potentially currently send, if it was not > constrained by restrictions imposed by its peer’s > incoming-window. > > To me that explicitly states that the value of the senders outgoing window > is not tied to the value of the receivers incoming window, i.e. that a > value of 0 for the senders outgoing window cannot reasonably be interpreted > as an expectation for the receiver to open its incoming window. > > I don't see a single sentence that would tie the session outgoing window > to link level credit, which is an entirely distinct mechanism. > > The one thing the spec does say of the remote-outgoing-window is that > "settling outstanding transfers can cause the window to grow". Settling > deliveries frees the sender from needing to track them which clearly > *might* enable a constrained sender to then send some more. Likewise a > received outcome might allow the sender to make room for further transfers > (though this isn't stated anywhere I can see it would seem a reasonable > interpretation). > > which implies that making the incoming window >> dependent on your peers outgoing window (as service-bus is doing) is >> probably not a safe thing to do. >> > > Tying the incoming window to the peers outgoing window can only make sense > if the sender is expected to keep the receiver up to date with regards to > the value of the outgoing window. If that is not the case, then I can't see > that the receiver can deduce anything from the outgoing window except that > possibly a value of 0 may be a hint that the sender is held up pending some > undefined action on the receiver part. > > Even if the sender was required to keep the receiver informed of the > outgoing window, having the receivers incoming window set to the outgoing > window of the sender is not terribly sensible in my view unless the > receiver would exapnd its incoming window if/when the sender expanded its > outgoing window. But doing that would essentially negate the whole purpose > of flow control anyway (i.e. a means for the receiver to protect itself > from excessive incoming traffic). > > In the case where the sender's implementation involves a fixed amount of >>> buffer space and requires messages to be settled before it can send more, >>> the receiver would not be able to know that without getting some signal. >>> So >>> to my mind that is the only case for which it would make sense to send an >>> outgoing window of 0. (I'm not sure how useful this is in practice and I >>> don't believe it applies to proton at present anyway). >>> >>> I think as it stands proton is violating the spec, and should be changed >>> to send a non-zero outgoing window. >>> >>> >> Per above I don't believe it is violating the spec, but given that it has >> been misinterpreted at least once, I certainly agree that some behavior >> change is warranted. I don't think we should do the max-frame-size thing >> though as this encourages the notion that the incoming-window is somehow >> dependent on the outgoing-window which as I said above is I think unsafe. >> >> I guess setting it to a large constant for now is fairly reasonable, but I >> do think we should encourage service-bus to make its implementation more >> robust in this regard. >> > > 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). While I agree the latter part of that is probably a stretch, I don't think the former part is. > If there is no required behaviour actually specified, and the intention > was to use the outgoing window as a hint of constraints on the sender then > sending 0 is the worst possible choice. Whatever the value, it is not > something the peer can rely on in anyway and using 0 when there are no > constraints seems to ignore even the apparent intent. I think the intended effect of always setting it to zero would be forcing the receiver to not buffer settlement notification. > So yes, my advice to service-bus and anyone else would be to ignore the > value. I think the question then is simply what is the least dangerous way > to set the mandated field for an implementation that wishes to avoid > interop problems. I think some very large fixed window is the best bet. > (I'm not sure I understand what the 'max-frame-size thing' is). > I think the best advice would be to ignore the value unless it is zero in which case you should ensure that you flush any buffered settlement notifications. --Rafael
