Rel 33: some thoughts and proposal...

Title: Rel 33: some thoughts and proposal...

All:

Sorry for a late notification, but here is a proposal for Rel 33 where a change in

the current semantics for Acknowledgements is proposed.

This is in the light of other issues that we are currently  trying to solve these days.

We would appreciate having at least the opportunity to present it to the TC at this meeting, if enough time...

Again, apologies for late notice but that is  a very recent conclusion of ours,

and we'd like at least to get early feedback if possible.

Jacques

-----------------------------------------------------------------

We'd like to propose a change in the semantics of sending an Acknowledgment.

Instead of sending the Ack when the message is received, the Ack. would be sent

when the message is made available to the server-side application/user. 

After some discussion related to faults/notifications, we believe this would help

significantly to get both Sender/Receiver aligned,

and also reduce the need for additional faults and notifications, always problematic

(e.g. if polling needed). 

The advantages we see with the new proposal are:

- More consistent semantically because the message is made available to

the user once acked, no more when buffered.

- Solves the async. failure notification problems.

- Makes Rel 50, Rel 52, and Rel 57 simpler.

- the main difference is for ordered groups, for pending out-of-order sequence.

- all semantics of RM features (guaranteed delivery, dup elim, ordering) would now be

about conditions of delivery to application. 

We have considered cases where Acks of received messages would be delayed

due to out-of-order sequences (not made available to app yet). 

To jot some memories back, this was decision we made at the first F2F

at Redwood Shores and was reverted back later as it may have payload

affect during retries. We believe this is a performance issue and

a trade-off on a functional behavior for a performance one. 

Performance can be handled without problem (see below) 

-------- detail: 

For implementations that are concerned about performance hit, an optimization

they could use is to only retry the lowest un-acked message in a grouped

ordered case, i.e., if msgs. 1,2,3 are sent and Sender hasn't received

acks. for 2 and 3, the Sender should not retry 3 until they get an ack. for 2.

For RMP impl. that doesn't worry about retries throttling the Receiver,

they might still send parallel retries. Either approach won't have any effect

on the end user behavior.