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

[David Fischer <david@drummondgroup.com>]

David Burdett has asked for Intermediate Acks and since he represents a
potential IM vendor, we need to honor that request.   . . . (shrug).  I too
think having the To Party MSH send two Acks is cumbersome but I don't know what
else to do unless the last IM will treat the DR as the Ack and also send it on
to the From Party MSH.

David Fischer
Drummond Group.

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Friday, August 17, 2001 11:02 AM
To: David Fischer
Cc: ebXML Msg
Subject: Re: T2, Proposed solution for ... Re: SyncReply and
ReliableMessagingMethod in QualityOfServiceInfo


David:

Please see below. My comments are bracketed by <ac> and </ac>.

Cheers,
-Arvola

-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: Arvola Chan <arvola@tibco.com>
Cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Date: Thursday, August 16, 2001 7:39 PM
Subject: RE: T2, Proposed solution for ... Re: SyncReply and
ReliableMessagingMethod in QualityOfServiceInfo


>Why can't end-to-end RM be completely independent of Intermediary RM.  I
see no
>reason to mix them up like this.  This is making things too hard -- Simple
is
>better.
>
>RM does not automatically imply duplicate detection.  What about
Intermediate RM
>with just Intermediate Acks so Intermediates do not worry about duplicates?
>This eliminates much of our problems.
>

<ac>
I agree that if intermediate MSHs do not perform duplicate elimination, then
achieving end-to-end reliable messaging is easy. I also agree that simpler
is
better. Do you see a real adavantage in retaining the use of intermediate
Acks?
</ac>

>Retries and RetryInterval are specified by the CPA.  CPPA does not consider
>Intermediaries so these are always end-to-end -- we have no choice (each
end of
>a hop might/will also have a CPA with these parameters).  I don't like the
idea
>that the Sender can't retry on lack of DeliveryReceipt because there may be
>cases where the Sender does not know there are Intermediates.  We can't
have the
>end behavior dependant upon the hop count.  Ends must behave the same all
the
>time.
>

<ac>
I find it cumbersome for the sending MSH to deal with two sets of retry
parameters,
one for the next MSH, the other for the destination MSH.

CPA's currently don't work with intermediaries. The retry and retryInterval
parameters to intermediaries can only be configured through proprietary
means. I guess I am in favor of doing away with intermediate Acks
altogether, or at least until they can be specified through CPA's.
</ac>

>RetryCount would not cause a recalculation of the Signature if it was in
Via
>(once again I am wondering why TraceHeaderList is not a sub of Via).  Of
course
>if Intermediates do not handle duplicates then we don't need RetryCount.
>

<ac>
I agree. Now I see the advantage of XMLDSIG which allows the exclusion of
certain
elements from the signature.
</ac>

>- David
>
>-----Original Message-----
>From: Arvola Chan [mailto:arvola@tibco.com]
>Sent: Thursday, August 16, 2001 8:16 PM
>To: David Fischer
>Cc: ebXML Msg
>Subject: Re: T2, Proposed solution for ... Re: SyncReply and
>ReliableMessagingMethod in QualityOfServiceInfo
>
>
>David:
>
>Please see comments inline bracketed by <ac2> and </ac2>
>
>-Arvola
>
>-----Original Message-----
>From: David Fischer <david@drummondgroup.com>
>To: Arvola Chan <arvola@tibco.com>
>Cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
>Date: Thursday, August 16, 2001 4:16 PM
>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.  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 ...).
>>
>>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
>
><ac2>
>We can specify in the QOS element that IM's do not adopt reliable messaging
>behavior, in which case no intermediate Acks should be generated by any one
>of them, and no duplicate elimination should be attempted by any of them.
></ac2>
>
>> 2) add a RetryCount attribute and change the way
>> IMs handle duplicates.
>
><ac2>
>I prefer to treat retries and retryIntervals as either end-to-end or
>hop-to-hop parameters, depending on the QOS specified by the sending MSH.
If
>the sending MSH wants no intermediate Acks, then these parameters are
>end-to-end. If the sending MSH wants intermediate Acks, then these
>parameters are hop-to-hop.
>
>I particularly don't like the idea of a retry count attribute in the
message
>header, because it implies the overhead of recomputating the digital
>signature. RNIF 1.1 makes use of a retry count; RNIF 2.0 does away with the
>retry count to eliminate this kind of overhead.
>
>The advantage of using intermediate Acks is that the sender MSH can stop
>retrying as soon as an intermediate Ack has been received from the next
>intermediary. I don't think it makes sense to retry on non receipt of the
>intermediate Ack and then subsequently to retry on non receipt of the
>DeliveryReceipt.
>
>I think the DeliveryReceipt has to be delivered reliably back to the sender
>MSH. It would not be an extra overhead if the DeliveryReceipt element can
be
>piggybacked on an application level business signal or business response
>message which is sent reliably. If the DeliveryReceipt message has to be
>sent on its own reliably, we should make sure that it does not ask for
>DeliveryReceipt from the original sender (so as to prevent looping).
>
>Once the sender MSH receives an intermediate Ack from the next
intermediary,
>it should simply wait for the DeliveryReceipt from the destination MSH. If
>this times out, it should report the delivery failure back to the sender
>application.
>
>I would suggest deriving this timeout value from the retry and
retryInterval
>parameters. When intermediate Acks are requested by the sender MSH, it
>essentially is willing to wait for the intermediate Ack for
>(retry+1)*retryInterval before reporting delivery failure to the sender
>application. That should also be the duration for which it is willing to
>wait for the end-to-end DeliveryReceipt from the destination MSH.
></ac2>
>
>>
>>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. 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.
>>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?
>></df>
>>
>
><ac2>
>My proposal above does call for sending the DeliveryReceipt reliably, but
>not requesting DeliveryReceipt for the DeliveryReceipt. It is not necessary
>to send intermediate Acks reliably because the previous hop sender is
>supposed to retry. Errors do not need to be sent reliably. For example, if
>the sender MSH stipulates that intermediate Acks are to be used, and one of
>the intermediaries is not capable of doing so, it can send an error message
>back to the sending MSH non reliably. If the sender MSH receives this error
>message OK, it will notify the sender application of the delivery failure.
>Otherwise, it will eventually time out waiting for DeliveryReceipt and then
>report the delivery failure.
>
>I believe error on Ack is compatible with my proposal above.
></ac2>
>
>>-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>