Re: T2, Proposed solution for ... Re: SyncReply andReliableMessagingMethod in QualityOfServiceInfo

[Arvola Chan <arvola@tibco.com>]

David and David:

Are you saying that a sending MSH must retry either if an intermediate
Ack has not been received or if the end-to-end DeliveryReceipt has not
been received, and that the resent message should carry an incremented
retry count if it is being resent due to non-receipt of the end-to-end
DeliveryReceipt?

If so, do we need two sets of retry parameters (i.e., retry count and
retry interval) to govern the two different kinds of retry?

Thanks,
-Arvola

-----Original Message-----
From: Burdett, David <david.burdett@commerceone.com>
To: 'David Fischer' <david@drummondgroup.com>; Arvola Chan
<arvola@tibco.com>
Cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Date: Friday, August 24, 2001 5:46 PM
Subject: RE: T2, Proposed solution for ... Re: SyncReply and
ReliableMessagingMethod in QualityOfServiceInfo


>David
>
>I largely agree with you specifically see below marked with <db></db>
>
>David
>
>
>-----Original Message-----
>From: David Fischer [mailto:david@drummondgroup.com]
>Sent: Thursday, August 16, 2001 4:14 PM
>To: Arvola Chan
>Cc: ebXML Msg
>Subject: RE: T2, Proposed solution for ... Re: SyncReply and
>ReliableMessagingMethod in QualityOfServiceInfo
>
>
>Arvola,
>
><df> comments inline </df>
>
>David Fischer
>Drummond Group.
>-----Original Message-----
>From: Arvola Chan [mailto:arvola@tibco.com]
>Sent: Tuesday, August 14, 2001 10:35 AM
>To: HUGHESJIM (HP-Cupertinoex1); ebXML Messaging (E-mail)
>Subject: Re: T2, Proposed solution for ... Re: SyncReply and
>ReliableMessagingMethod in QualityOfServiceInfo
>
>
>My opinion is that the current spec is so broken that extensive
>changes may be necessary to get end to end reliable messaging
>over multiple hops to work properly. I agree with you and that
>intermediate Acks used by the intermediaries are the likely source
>of the problem.
><df> agreed </df>
>
>If we stipulate that only the sending MSH and the receiving MSH
>adopt the reliable messaging behavior, I believe end to end reliable
>messaging will work regardless of whether intermediaries are
>present. However, this may make reliable messaging not very
>useful for certain use cases, e.g., where the sending MSH does
>not have a permanent Internet presence.
>
><df>  This is not all that hard if we keep the present structure of
>DeliveryReceipt as the end-to-end Ack and the Acknowledgement element as
the
>IM
>hop Ack.
><db>Agreed</db>
>This is already in the spec and nothing about these elements needs to
>be changed.  We only need to specify in section 10 that if the To Party MSH
>gets
>a DeliverySemantics=1&o1 then send a DeliveryReceipt to the From Party MSH
>(along with ...).
><db>I think I agree.</db>
>
>Unfortunately, this does not deal with the duplicate problem.  If I (the
>From
>Party MSH) don't get a DR back, then I will retry (Retries and
RetryInterval
>are
>end-to-end parameters, not hop-to-hop).  I don't want any IMs rejecting my
>retry
>due to duplicates.  We can fix this by either:
> 1) telling the IMs not to worry about duplicates or
> 2) add a RetryCount attribute and change the way
> IMs handle duplicates.
><db>I think that a Retry Count is the best way to go handle this rather
than
>a different MessageId that I suggested earlier.</db>
>
>The way we handle duplicates now is definitely broke.  </df>
>
>I now realize there is a problem in my previous proposal to have
>the sending MSH stop retrying once it gets an Ack from the next
>intermediary, and then wait for the DeliveryReceipt from the
>receiving MSH. Unless the DeliveryReceipt is sent reliably, it
>may get lost, so the sending MSH may falsely notify the sending
>application that reliable messaging has failed.
><db>Yes and no. If the DR is being sent asynchronously on a spearate
session
>then it needs to be sent reliably. If it is being sent synchronously on the
>same channel then the DR is the acknowledgement and so does not need to be
>sent reliably.</db>
>
>If the DeliveryReceipt
>is sent reliably, then it may require end to end acknowledgement
>from the sending MSH, possibly triggering an infinite chain of
>DeliveryReceipt messages. (A possible workaround may be to
>require that if a DeliveryReceipt is sent reliably and on its own,
>then it must not request for DeliveryReceipt.)
>
><df> agreed -- no DR for a DR and no Ack for an Ack and no Error on an
>Error.
><db>Completely agree</db>
>We can get carried away with RM if we start sending Acknowledgements or DR
>reliably.  We also have to pick either Ack on Error or Error on Ack but not
>both.  I think I prefer Error on Ack... I'm not sure?
><db>This depends on whether the original message was being sent
>synchronously for the same reasons as in the Delivery Receipt discussion
>above.</db>
></df>
>
>-Arvola
>
>-----Original Message-----
>From: HUGHES,JIM (HP-Cupertino,ex1) <jim_hughes@hp.com>
>To: ebXML Messaging (E-mail) <ebxml-msg@lists.oasis-open.org>
>Date: Monday, August 13, 2001 7:17 PM
>Subject: RE: T2, Proposed solution for ... Re: SyncReply and ReliableMessa
>gingMethod in QualityOfServiceInfo
>
>
>>Question: Does "reliable messaging" mean that the initial MSH (and maybe
>>intermediate node MSHs) needs to consider this as a quality request and,
if
>>possible, pick the "most" reliable transport available? Or, is this just a
>>protocol for the receiving MSH to send a confirming ACK back to the
sending
>>MSH?
>>
>>I think it's the latter, and thus there is no directive for intermediate
>>node links to use the RM protocol to confirm among themselves that this
>>message got through. From their perspective, the overall MSH Ack looks
like
>>a higher level function to them... and, in fact, it seems to me that
having
>>the intermediate links try to use their own version of RM between their
>>endpoints really complicates the picture and maybe they should be
>prohibited
>>from trying to use RM since they aren't the start/end-points for the
>overall
>>message... IMO.
>>
>>jim
>>
>>
>>
>>> -----Original Message-----
>>> From: Arvola Chan [mailto:arvola@tibco.com]
>>> Sent: Sunday, August 12, 2001 9:30 PM
>>> To: David Fischer; Burdett David
>>> Cc: ebXML Messaging (E-mail)
>>> Subject: Re: T2, Proposed solution for ... Re: SyncReply and
>>> ReliableMessaging Method in QualityOfServiceInfo
>>>
>>>
>>> David:
>>>
>>> My comments are bracketed by <ac> and </ac>.
>>>
>>> Cheers,
>>> -Arvola
>>>
>>> ----- Original Message -----
>>> From: "David Fischer" <david@drummondgroup.com>
>>> To: "Arvola Chan" <arvola@tibco.com>; "Burdett David"
>>> <david.burdett@commerceone.com>
>>> Cc: "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>
>>> Sent: Sunday, August 12, 2001 2:33 PM
>>> Subject: RE: T2, Proposed solution for ... Re: SyncReply and
>>> ReliableMessaging Method in QualityOfServiceInfo
>>>
>>>
>>> > Arvola,
>>> >
>>> > What if I am sending to you and you are using an IM for
>>> some reason, e.g.
>>> no
>>> > persistent connection?  I might not even know and since I have no
>>> agreement with
>>> > that IM (my agreement is only with you), I cannot be responsible for
>>> putting the
>>> > CPAid in the Via -- there is no CPAid.  What I can do is
>>> fill in the Via
>>> fields
>>> > as much as I am able in case there is an IM I am not aware
>>> of.  This, IMO
>>> will
>>> > be a very common use case.
>>> >
>>> > This exact same situation would arise if you used multiple
>>> MSHs where one
>>> was a
>>> > mailroom.
>>> >
>>>
>>> <ac>
>>> I must admit that your use case is a very valid one and I
>>> have not made
>>> provision for
>>> it.
>>>
>>> Come to think of it, when I suggested that the sender MSH
>>> should dictate if
>>> all intermediaries
>>> should use reliable message or not at all, it is not strictly
>>> necessary for
>>> the sender MSH to
>>> know that intermediaries are involved, all it is choosing is between
>>> reliable message with
>>> intermediate Acks vs reliable messaging without intermediate Acks.
>>>
>>> As you have indicated earlier, "Even though the ends don't
>>> need to know
>>> about the IMs,
>>>  it is critical that the IMs realize their role." There, the
>>> IMs should be
>>> able to respect the
>>> directive from the sender MSH to use intermediate Acks or not.
>>> </ac>
>>>
>>> > You are correct, I need to be more clear.  I believe the
>>> sender MSH would
>>> > construct the Via.  This Via would pass to the first IM MSH
>>> who would
>>> construct
>>> > a new Via (possibly very similar to the original) and pass
>>> this new Via to
>>> the
>>> > next hop's MSH.
>>> >
>>> > NEW PROBLEM WITH MULTI-HOP?
>>> > This brings up a good point.  I (the From Party MSH) know
>>> how to send to
>>> you
>>> > (the To Party MSH) because I can look up your connection
>>> info in the CPA
>>> > Database based upon a CPAid and a ChannelID.  This info
>>> might not reside
>>> in the
>>> > To PartyID element.  If my message goes through an IM, how
>>> does the IM
>>> know
>>> > where to send?  I don't send to you, I send to my IM.  If I
>>> am using an
>>> IM, does
>>> > that mean any time I make an entry in my database I also
>>> have to duplicate
>>> that
>>> > info to my IM (and they to each of their IMs etc.)?  This
>>> would not be
>>> > acceptable.  Maybe this connection info MUST reside in the
>>> To PartyID?
>>> This
>>> > would not be a problem for single-hop.  Maybe the Receiver
>>> connection info
>>> needs
>>> > to be put in the Via?
>>> >
>>>
>>> <ac>
>>> I agree with you this is a problem. The intermediary needs to
>>> be configured
>>> with the
>>> Endpoint and various characteristics for the To Party (or the
>>> Endpoint for
>>> yet another
>>> intermediary who can route messages to the To Party directly
>>> or indirectly
>>> and its
>>> characteristics). My understanding is that CPPs and CPAs
>>> currently deal only
>>> with
>>> the point to point case. Therefore, there is no automated way
>>> to configure
>>> intermediaries
>>> using CPAs. This is something the CPP/A TC will have to
>>> address in its 2.0
>>> spec.
>>> </ac>
>>>
>>> > 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 subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>