RE: End-to-end RM

[David Fischer <david@drummondgroup.com>]

I'm absolutely aghast!  We add RM to try to improve the chance a message makes
it through but instead we block the message if an IM hop does not support RM?
NO!  Our job is to get the message to the end, not short circuit on
technicalities.  If this is the way RM works then forget IM RM -- do end-to-end
RM only!

OTOH, I continue to support David Burdett's plan.  It seems like the best of
both worlds.

David Fischer
Drummond Group.

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, August 14, 2001 3:51 PM
To: christopher ferris
Cc: ebXML Msg
Subject: Re: End-to-end RM


Some rejoinders below.

Regards,
Marty

********************************************************************************
*****

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
********************************************************************************
*****



christopher ferris <chris.ferris@east.sun.com>@Sun.COM on 08/14/2001
03:28:46 PM

Sent by:  Chris.Ferris@Sun.COM


To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   ebXML Msg <ebxml-msg@lists.oasis-open.org>
Subject:  Re: End-to-end RM



Marty,

Please see below.

Cheers,

Chris

Martin W Sachs wrote:
<snip/>

>
> IMO, an MSH, unless it is embued with an intellegence of its own,
> cannot be directly responsible for addressing a delivery failure
> along a message path for a message for which it has already received
> an acknowledgment. It should only be responsible for notifying
> the sending party (the application or its administrator, etc.)
> of the details of the delivery failure.
>
> MWS:  The MSH which is responsible for notifying the From Party
> of delivery failure is the From
> Party's MSH.  The evidence of delivery failure is exhausting the
permitted
> number of retries without receiving an acknowledgment.  So, there is no
> issue about a delivery failure along a message path for which it has
> already
> received an acknowledgment.  IF the acknowledgment came, the message was
> delivered to the destination persistent store.  Of course, I have the
> end to end protocol in mind when I say this. A protcol which permits and
> intermediary to acknowlege the message and further, permits the message
> to be lost farther down the path is not reliable messaging.

Actually, there are three cases as I see it coming from my perspective
where reliability is achieved by a reliable hand-off between two adjacent
MSH nodes along a message path consisting of nodes ALL of which support
the RM protocol or an equivalent (or superior) transport-specific reliable
messaging mechanism.

The first case is one where the originating MSH node (the From Party's
initial MSH) cannot deliver a message to the next MSH node in the
message path following the specified number of retries each separated by
the retry interval. In this case, that MSH needs to communicate (somehow
through some unspecified interface) the delivery failure. This could be
as trivial as a logging of the failure in an error log or it could be
achieved through some call-back to the sending application or its
proxy. Regardless, the mechanism can't be specified as there are simply
too many equally valid possibilities from which to choose.

MWS:  I agree as long as the MSH SHALL communicate the delivery failure.

The second case is one which involves an MSH node that is NOT the
initial From Party MSH. In this case, as defined in section 10.4,
an Error message is generated and sent to the From Party with
an errorCode of DeliveryFailure and a Severity of Error in the event that
the message cannot be delivered to the next MSH node in the message
path. The initial From Party MSH node that receives such an error MUST
(somehow, probably using the same mechanism as described above) notify
the From Party of the delivery failure.

MWS:  The delivery-failure message SHALL be send to the From party
using reliable messaging.  Note that since the delivery-failure
message has its own message ID, this is not a case of a potential
endless loop of delivery-failure messages, especially since the
process ends when a deliverly failure is recognized.

The third case is defined as the case where the ultimate destination
MSH of the To Party cannot, for some reason, forward the message to
the To Party (the "application"). This case is equivalent IMO to the
second use case above. The fact that the message is persisted on
disk by the ultimate MSH in the message path is irrelevant from the
perspective of the From Party if the message cannot be processed. It is
no different in my mind than if the message was "lost" at some point
along the way.

MWS:  The spec should state that it is the responsibility of the
intermediate node (and, in fact, the To node) to guarantee that if it
fails and recovers, it will continue to process the received messages
in its persistent store. This should be a requirement statement,
not a system design statement.

The question becomes then, should the DeliveryFailure message be delivered
reliably. I think that if it were, that it closes the loop except in
extreem cases where the DeliveryFailure message results in a delivery
failure
of its own, in which case some external mechanism is in play (pick up
the phone and figure out what the problem is, you have bigger problems
than can be addressed with this or any other protocol one could define
such that an implementation were affordable by any but the Fortune 500!).

MWS:  As I pointed out, a delivery failure indication on a delivery failure
message is not a problem and will not lead to an endless repetition of
delivery-failure messages. In any case, any delivery failure in general is
the
result of an extreme situation such as a communication network outage or
a failure of the destination node, that will require a phone call.

Any manner of positive acknowledgment should, IMO be optional and should
IMO
be a function of the receiving application/party notifying the sending
party/application of the receipt. By this I don't necessarily mean that
the "application" necessarily support such a function directly. This could
be
handled by a proxy of the "application" (e.g. a B2BI server [which possibly
has as
a component of itself an MSH]).

Why?

Because under many circumstances, an application-level response received
within a reasonable, possibly agreed-upon, timeframe can serve as an
equally effective
positive acknowledgment without adding the overhead of an unnecessary extra
message
between the parties.

MWS: But messages are lost for "ordinary" reasons such as a noise hit on an
underlying IP packet.  Without an RM acknowledgment, all retries are pushed
up
to the application level.  Reliable Messaging, with an RM acknowledgment,
relieves
the application of dealing with those low-level retries.

In RosettaNet, business signals such as the ReceiptAcknowledgment, etc.
can serve the purpose of providing the sending party with an effective
positive acknowledgment that the message has reached its ultimate
destination. Adding in a MSH-specific end-to-end acknowledgment would be
redundant and possibly meaningless in certain use cases such as
non-repudiation.

I do not think that we can require that the MSH be provided with the
authorized private keys required to sign a non-repudiation receipt which
in the case of non-repudiation is what determines whether the message
was indeed received from the perspective of the From Party.

MWS:  I completely agree.  That's one reason why a low level RM
acknowledgment
is worthwhile. It has no business information of any sort and doesn't
have to be signed.

RosettaNet, as well as ebXML BPSS provide for a business transaction
time-to-live, after which, in the absence of the response business
message, the transaction, and possibly the whole conversation/exchange,
are considered null-and-void.

>
> I don't ever recall in any context that we ever said that RM can be
> achieved
> over unreliable links. Possibly you mean unreliable transports, such as
> HTTP, which is what the RM protocol has been designed to address.
>
> I believe that if a sending party/application says that a message is
> to be delivered with a deliverySemantics of OnceAndOnlyOnce that this
> quality of service MUST be supported (whether by the ebXML RM protocol
> or by "transport" specific means, such as in the case of MQSeries)
> by all MSH nodes in a message path. Maybe the spec doesn't say that
> explicitly, in which case we should address this to make it crystal
> clear in the errata. Something along the lines of:
>
>      An MSH receiving a message with a deliverySemantics
="OnceAndOnlyOnce"
>      that does not support that level of QOS MUST send
>      an Error message to the To Party with an errorCode of NotSupported
>      and a Severity of Error.
>
> MWS:  This is back into the discussion of end to end vs. hop by hop.  As
> long as the RM protocol is end to end, it doesn't matter whiat quality of
> service is supported in between.  Of course a lousy link in the middle
will
> cause more RM retries but it won't violate the committments that RM makes
> to
> the endpoint parties.

Please see above.

>
> Yes, this would mean that this particular message path would be
permanently
> blocked until such time as the offending node is either removed from the
> message path or it is enabled with the RM capability. I don't see this as
a
> problem that we need to solve, nor do I ever recall it as being a
> requirement.
> Possibly you are referring to the requirement that RM be achievable over
> unreliable transports such as HTTP and SMTP. That is a very different
> requirement
> than that RM be achievable through intermediary MSH nodes that don't
> support
> that level of QOS.
>
> Cheers,
>
> Chris
>
> [1] http://lists.oasis-open.org/archives/ebxml-msg/200107/msg00026.html
>
> David Fischer wrote:
> >
> > Chris,
> >
> > I think we have established on the list the need for end-to-end RM.
> However, on
> > the call, you asserted the reverse.
> >
> > Many times we have made the statement in the various F2F meetings that
> "reliable
> > messaging can be achieved over unreliable links."  Yet on the call you
> said that
> > if RM is requested by DeliverySemantics=1&o1, then if a link cannot do
RM
> it
> > must return an error?  This could actually be a permanently block any
RM
> flagged
> > message!  These two ideas are not compatible.  The only way to provide
RM
> over
> > unreliable links is to "close the loop" with an end-to-end Ack.
> >
> > I must continue to maintain that an end-to-end MSH level Ack is
required.
> This
> > is already in the spec and it is called DeliveryReceipt.  The only
change
> I am
> > asking for is that DeliveryReceipt be appropriately added to section
10.
> >
> > Regards,
> >
> > David Fischer
> > Drummond Group.
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>