RM Group Definitions

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

Our initial rendering of the RM spec just assumed that MS layer was sending 
messages needing "reliable delivery", with no context of a "conversation" 
or "multiple TPAs" assumed -- this was left to other MS functions or a 
higher layer. The grouping of what would otherwise be independent messages 
into an "RM Group" was just to provide performance/implementation 
improvements. If the MSH needs to group messages for other reasons, then we 
should have a discussion about this and see if the RM Group concept is 
embedded in that architecture, or should be separate in a lower layer in 
the MSH...

Regarding Marty's comment on efficiency, we assume that the higher-level 
layer using RM would establish the size of an RM Group. Marty feels that 
the upper layer BP should not do this (correct, Marty?), so we need to 
decide architecturally if the MSH should determine this grouping and how it 
is done. The trivial case, of course, is to just set the size of each RM 
Group to be one message, which forces MSH-level ACKs for each message.

Jim

At 10:27 AM 8/28/2000 -0400, Farrukh Najmi wrote:
>It was my interpretation that an RM-Group is between a specific 
>sender/receiver/transport. Further I
>assume the sender/receiver mapped to a specific TPA instance. This led to 
>the assumption that pollling
>frequency could be specified in TPA. Marty, you seem to be implying that 
>an RM-Group could contain
>messages related to multiple TPAs. Which is the correct assumption about 
>RM-Group?
>
>BTW This sort of thing is again pointing to the need of clarifying what an 
>RM-Group is.
>
>6) One or more messages between the Sender and Receiver on the same 
>Sender-Receiver-Transport triplet
>may be sent using Reliable Messaging semantics. This sequence messages is 
>termed an "RM-Group".
>
>--
>
>Regards,
>Farrukh
>
>mwsachs@us.ibm.com wrote:
>
> > Sspecifying polling frequency in the TPA is not appropriate because a given
> > TPA involves two particular partners while the RM function involves all
> > TPAs using the particular transport path.  Each TPA might specify different
> > polling frequencies.  Oour goal should continue to be to keep the RM
> > details transparent to the application (and therefore transparent to the
> > TPA).  One could think about a TPA which defines the relationship between
> > two Messaging Service instances but this should be a last resort.
> >
> > The RM proposal indeed increases efficiency by decreasing the ACK frequency
> > but as I discussed in my comments to the current version of RM, this
> > efficiency is at the cost of substantially increased latency for each
> > message since no received message can be passed up to the application until
> > all messages in the RM group have been successfully received.
> >
> > 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
> > 
> *************************************************************************************
> >