Re: RM Group Definitions

[mwsachs@us.ibm.com]

Jim,

Correct - the upper layer BP should not establish the group size.  Each
process in the BP layer has a view only to itself.  With the BP processes
requesting group size, the RM service would have to somehow resolve
conflicts.  Using the largest requested group is one approach - but that
would be larger than most processes want and therefore impair their
latencies.  Note also that once the RM service is into resolving conflicts
on group size, no BP process knows what the actual group size is anyway.

The trivial case which you mention is probably not the best answer.  If the
RM service, on its own, can only set the group size to 1, we might as well
simplify the definition and have only a group size of 1.  That would be the
worst case for the number of ACKs and the best case for message latency.

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
*************************************************************************************



Jim Hughes <jfh@fs.fujitsu.com> on 08/28/2000 12:31:48 PM

To:   ebxml-transport@lists.ebxml.org
cc:
Subject:  RM Group Definitions



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
> >
>
*************************************************************************************

> >