Re: [ws-rx] Proposed NEW ISSUE: Alignment and Refinement of Definitions for Delivery Assurances

[Tom Rutt <tom@coastin.com>]

Jacques Durand wrote:

>
> Tom:
>
> Step #1 looks OK to me.
>
> Step #2 I am not sure what we try to achieve here.
> I see no harm having the DAs *defined*  as predicates, independently 
> from the functions that support them. I have no issue with leaving out 
> any mention of the protocol or other functions in these defs. If we 
> try to identify RMS/RMD functions that support them, that may be 
> useful as an implementation guide, but do they need to be part of the 
> definition?
>
The use of the term "function" is purely for definition purposes.  These 
functions define obligations and permissions for both RMS and RMD.

EXACTLY ONCE DA has all the obligations and permissions of "AT LEAST 
ONCE" but also adds the duplicate elimination function.

I find the concept of function an easy way to define this.

the OrderedDelivery in the spec can be added as a "function" to either 
EXACTLY ONCE or "AT LEAST ONCE".  Thus it is really a function
to add to either DA.

Now the Best Effort Delivery is only combined with EXACTLY ONCE in the 
spec.  This seems odd.  I prefer we take it away, or if we have it
it should be able to be combined with EXACTLY once and AT LEAST ONCE.  
However, I do not believe it is compatible with ordered delivery, since 
orderede delivery definition seems to disallow holes in the delivery 
sequence.

Anyway, the use of the term "function" is just for definition purposes.  
If we can come up with another word for a group of obligations I would 
be happy to go with that word rather than function.  In fact, 
WS-Reliability uses the term "reliabilty features" to refer to the trio: 
"guaranteed delivery" , "duplicate elimination", and "guranteed message 
ordering".   

Tom Rutt,

> This said, I still think DAs could be defined more precisely - e.g. 
> AtLeastOnce is vague as where the error should be raised - and whether 
> these errors should translate into app notifications or some form of 
> exposure to app (there does not seem to be any requirement here - yet 
> this can be seen as part of the contract RMD-AD, and also maybe RMS-AS...)
>
> Step #3: although the protocol seems to do unnecessary efforts when 
> AtMostOnce DA alone is required, I must say that from the user 
> viewpoint this DA still makes sense: the elimination of duplicates is 
> the most important aspect of it. The inadequacy of the protocol to 
> this DA is mostly an optimization issue (and also an unnecessary 
> implementation burden for some cases). The other difference with 
> AtLeastOnce DA, from the RMD-AD contract perspective, is that in the 
> latter, an error must be raised if the message is dropped after reception.
>
Why should the sender retransmit until ack, if the RMD can throw it 
away.  Adding the BEST EFFORT DELIVERY as a reliability "feature",
while requiring the RMD to keep the knowledge of receipt in it ack state 
still seems odd to me.  If we want such a contractual permission, why not
also allow it to be combined with "AT LEAST ONCE".

Tom Rutt

> I think the issue is a more general one: should this DA as well as 
> other DAs be part of this spec, now that the protocol has a life of 
> its own? I'd prefer to see DAs expressed in a different doc, or at 
> least in a clearly separate section. Looks like another editorial issue.
>
> Regards,
> Jacques
>
>
> -----Original Message-----
> From: Tom Rutt2
> Sent: Wednesday, September 28, 2005 10:17 AM
> To: wsrx
> Subject: [ws-rx] Proposed NEW ISSUE: Alignment and Refinement of 
> Definitions for Delivery Assurances
>
>
> NEW ISSUE - Alignment and Refinement of Definitions for Delivery 
> Assurances
>
> Description:
> I took an action Item to align the Delivery Assurance definition text in
> the body document with the resolution of Issue 009.
>
> Source: Tom Rutt, Fujitsu
>
> Justification:
> The resolution of Issue 009 is documented at:
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14682/ReliableMessagingIssues.xml#i009 
>
> :
>
> It is best if the Delivery assurances are defined in only one place in
> the document.
>
> The definition of Delivery assurances is simplified by introducing the
> concept of Reliability Functions.
>
> Proposals:
>
> The proposal to resolve this ISSUE is presented in Three Steps.
>
>
> Step 1) of Proposed Resoluton: Change the use of in line definitions in
> the proposal for Issue 009 to references to the definitions in section
>
> Resulting text for Proposal for Issue 009:
>
> "
> <wsrm:DeliveryAssertion mode="[AtLeastOnce|AtMostOnce|ExactlyOnce]"
> ordered="[xs:boolean]"? ...="" >
>
>
> /wsrm:DeliveryAssertion
> A policy assertion that makes a claim as to the delivery assurance policy
> observed by the destination endpoint.
>
>
> /wsrm:DeliveryAssertion/@mode
> This required attribute specifies which delivery assurance is asserted.
>
>
> A value of 'AtMostOnce' means that the Delivery Assurance "at Most Once,
> defined in section xxx, is asserted.
>
>
> A value of 'AtLeastOnce' means that the Delivery Assurance "At Least 
> Once",
> defined in section xxx, is asserted..
>
>
> A value of 'ExactlyOnce' means that the Delivery Assurance "Exactly 
> Once",
> defined in section xxx, is asserted.
>
>
> /wsrm:DeliveryAssertion/@ordered
> This attribute, of type xs:boolean, specifies whether, or not, the
> "in order" reliability function defined in section xxx is asserted. .
> A value of 'true' asserts that the "in order" reliability function is
> required.
> A value of 'false' asserts that the "in order" reliability function is
> not required.
> If omitted, the default implied value is 'false'.
> "
>
>
> Step 2) of Proposed Resolution: Clarify Definitions of Delivery
> assurances, using concept of reliability functions
>
> The term "Delivery assurance" is used to refer to a set of engaged
> reliability functions associated with a Reliable Messaging Sequence.
>
> Fundamental Reliability Functions:
> * Guaranteed Receipt:
> o RM-Source must buffer the message, to allow for potential
> re-transmission, until an acknowledgement is received from the
> RM-Destination for that message.
> o RM-Destination must return an acknowledgment upon successful receipt
> of the message.
> * Duplicate Elimination:
> o No obligations on RM-Source.
> o RM-Destination must not deliver to application destination any message
> which has the same ID as a previously delivered message.
>
> In addition, to allow the definition of Delivery assurance "at most
> once", as in the resolution of Issue xx, the following "reliability
> function" is defined
> * Best Effort Delivery
> o No obligations on RM-Source
> o RM-Destination is allowed to abort delivery of received messages to
> application destination if it cannot delivery the received message.
>
> Note: the Best Effort Delivery function is really a function at all: it
> has no obligations, while it does have a contractual permission for not
> delivering a message which it has received. This does not seem to be a
> valid reliability function.
>
> The following table specifies the delivery assurances in terms of
> engaged reliability functions.
>
> Delivery Assurance |Guaranteed Receipt |Duplicate Elimination |Hold for
> Prior |Best Effort Delivery
> At least once y n n n
> Exactly once y y n n
> 'At most once' y y n y
>
> The following reliability function may be asserted along with any of the
> above Delivery Assurances:
>
> * In-order:
> o Order is determined by the value of the RM message number. Ordered
> delivery would mean that the messages would be delivered in ascending
> order of the message number value.
> o No obligations on RM-Source
> o RM-Destination must hold a received message, for delivery to the
> application destination, until all messages with smaller message number
> within a sequence have been delivered to the application destination.
>
> Note: The guaranteed delivery function is the only one which puts an
> obligation on the rm-source. All of the reliability functions defined
> above place obligations (or permissions in the case of "Best Effort
> Delivery") on the rm-destination.
>
>
> ------------------
>
> Step 3) of Proposal: Refinement of DA Definitions Required to Resolve
> Discrepancy with traditional semantics of "At Most Once"
>
> The delivery assurance "at most once", as defined in WS-rm spc, seems
> out of place. If the ws-rm spec is going to allow for "best effort
> Delivery" as a conformant behaviour contract for an RMD under special
> circumstances, why is it only allowed in combination with Guaranteed
> Delivery and Duplicate Elimination reliability functions.
>
> I propose two ways to fix this discrepancy:
>
> 3 a) Remove the concept of "at most once" as defined in this spec.
>
> The traditional use of the term "at most once" delivery assurance
> requires engagement of the duplicate elimination function without
> requiring the guaranteed delivery function. Since it has been agreed
> that the ws-rm protocol will always support the guaranteed Receipt
> function, this traditional concept of "at most once" is not compatible
> with this protocol.
>
> 2 b) define two new delivery assurances with Best effort Delivery (for
> consistency)
>
> Delivery Assurance |Guaranteed Receipt |Duplicate Elimination |Hold for
> Prior |Best Effort Delivery
> At least once BED y n n y
> Exactly once BED y y n y
>
>
> Approach 3b) adds complexity to the Delivery assurance assertion
> mechanism. It does not seem to go along with the concept of Reliable
> messaging, and systems which do this should be considered as acting
> outside the scope of the WS-rm specification.
>
> I prefer proposal 3a).
>
>
> -- 
> ----------------------------------------------------
> Tom Rutt        email: tom@coastin.com; trutt@us.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133