Re: RM Group Definitions

[Jim Hughes <jfh@fs.fujitsu.com>]

History:

- in Fujitsu's original July presentation, we explained that each
reliable message had an associated expiration time set for the message. A
counter was used so the loss of a message could be quickly detected by
the receiver. A message-service level ACK was synchronously returned for
each message and the expiration time used to detect lost messages by the
sender.

- in the July meeting, there was strong vocal opposition to ACKs for
*each* message, so we moved to a grouping concept in response. How to
identify the size of a group (BP? MSH? TPA?) was not defined and remains
an open question in the draft RM spec. There is a value shown for this in
the current draft - "RM-Group Count".

- since the header has a presumed unique MessageID, there was push to use
it as the "counter" for easy detection of duplicates or lost
messages. We've kept the counter concept in the latest draft, known as
the "Sequence Number".

- originally, we specified that the message's Expiration Time was a QoS
value specified by the application, and this was passed with the message
so the receiver's MSH could use it. The current draft needs to have an
expiration time set on the Sender side (for timeout) but it is not passed
to the receiver and thus is not in the message. We still have not decided
how this value is determined, and the discussion is not too far removed
from the "who sets the RM-Group size" discussion.

If the concept of grouping messages (to reduce the number of
message-service level ACKs) is burdensome, Fujitsu could revert to our
original proposal (see
http://lists.ebxml.org/archives/ebxml-transport/200007/msg00094.html
for details) and work from there.

However, we'd prefer not to make changes to the draft spec until some of the requirements and architecture are clearer. (I had thought several days ago that we should be updating our TRP requirements document, but today I'm not sure that the group even agrees on that point!)

At the risk of generating more email (thanks, but I get enough TRP email these days!), let me assert some points that seem to be common in recent emails:

a) eliminate the use of RM-Groups. MSHs must process individual messages in a reliable manner and post an error if the delivery was not completed.

--> note: if we agree to this, we can avoid all the email discussions on complexities of how groups are used, set, involved with BP-level activities, etc.!

b) successful RM delivery means the MSH on the receiver side got the message. No upper-level BP is involved.

c) if an MSH knows that the transport is reliable, it may make use of this knowledge and not use RM semantics for the message. We will then need to indicate in the Routing Header (most likely place) that even though the Message Header specifies "AtMostOnce", there is no MSH-level ack expected by the sender.

d) Routing Header elements are added for each MSH-MSH link in the path. RM needs to have some fields in this header, but there may be requirements for other fields (security, audit, etc.).

e) the sending application flags *each* message as reliable or not.

f) messages sent reliably on a sender-transport-receiver triple should be received/processed in the same sequence. Marty has expressed several times that this needed to be true for RM-Groups, and if we eliminate grouping, the principle should apply to singleton messages. This concept follows KISS and was in the original Fujitsu proposal.

g) For simplicity, ACKs which indicate successful receipt of a reliable message are just MSH-level acks. The presence/absence of BP or transport level ACKs is orthogonal. (this one had several differing viewpoints!)

There are probably more architectural points we could resolve, but if we can get past these now, I can make progress on a revised RM draft.

===> Please post comments/agreements/disagreements to the above points by COB 1 September (or let me know if you need more time).

Thanks,

Jim

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


At 09:43 AM 8/29/2000 -0400, Christopher Ferris wrote:
> I agree. It isn't clear to me where the notion of BP-level
> or application-level grouping came from as I haven't had
> an opportunity to read ALL of the messages sent during my
> vacation, but this seems to me to be something we should 
> steer well clear of.
>
> Chris
>
> richard drummond wrote:
> > 
> > i don't see grouping messages as being a key point of a reliable messaging
> > spec. yes it is important for performance... but not for reliable messaging.
> > that is why i think we should forgo it on this round and concentrate on the
> > rm part of things.... best regards, rik