OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrm] R: [wsrm] Rel YY


Hello Eugene,

Much better.
I totally agree with you.
Thanks,

Iwasa


> Hello Iwasa,
> I agree with you that proposal 2) is more convenient: efficiency,
readability... But, even the limitation to one interval SHOULD be removed
using a syntax like this:
>
> Proposal 3):
> -----------
>
>         <RefToGroupId
aaaaa.bbbbb.cccccc/xxxxxxx/yyyyyy/zzzzzz/groupIdValue>
> <SeqInterval NmbrStart=1, SeqNumbrEnd=5>
> <SeqInterval NmbrStart=7, SeqNumbrEnd=7>
> <SeqInterval NmbrStart=9, SeqNumbrEnd=10>
>         </RefToGroupId>
>
> This covers all patterns: (like here 1-5;7; 9-10)using ONE <RefToGroupId>
element.
>
> Regards,
> Eugene
>
> -----Original Message-----
> From: iwasa [mailto:kiwasa@jp.fujitsu.com]
> Sent: Mittwoch, 24. September 2003 06:47
> To: Doug Bunting; Paolo Romano
> Cc: 'Jacques Durand'; wsrm@lists.oasis-open.org
> Subject: Re: [wsrm] R: [wsrm] Rel YY
>
>
>
> I also agree with Jacques proposal,
> since I was considering a resolution and struggling
> to find out a way to send multiple acks in a single Ack message,
> which is our requirement.
>
> See the following example of five Acks in a single
> Ack message:
> 1) Without SequeceNumber:
>     <Response>
>         <RefToGroupId>
>               aaaaa.bbbbb.cccccc/xxxxxxx/yyyyyy/zzzzzz/group1
>         </RefToGroupId>
>         <RefToGroupId>
>               aaaaa.bbbbb.cccccc/xxxxxxx/yyyyyy/zzzzzz/group2
>         </RefToGroupId>
>         <RefToGroupId>
>               aaaaa.bbbbb.cccccc/xxxxxxx/yyyyyy/zzzzzz/group3
>         </RefToGroupId>
>         <RefToGroupId>
>               aaaaa.bbbbb.cccccc/xxxxxxx/yyyyyy/zzzzzz/group4
>         </RefToGroupId>
>         <RefToGroupId>
>               aaaaa.bbbbb.cccccc/xxxxxxx/yyyyyy/zzzzzz/group5
>         </RefToGroupId>
>     </Response>
>
> 2) With SequceNumber
>     <Response>
>         <RefToGroupId SeqNmbrStart=1, SeqNumbrEnd=5>
>               aaaaa.bbbbb.cccccc/xxxxxxx/yyyyyy/zzzzzz/group1
>         </RefToGroupId>
>     </Response>
>
> In conclusion, SequenceNumber is reasonably
> desired to realize multiple Acks in a single Ack message.
> Since we should not preclude a possibility of efficient and scalable
> way of Duplicate Checking, and Multiple Acking.
>
> We may want to define default value of "0" as SequenceNumber for
> non-ordered delivery, when it was ommitted.
>
> Thanks,
>
> Iwasa
>
>
> ----- Original Message ----- 
> From: "Doug Bunting" <Doug.Bunting@Sun.COM>
> To: "Paolo Romano" <paolo.romano@dis.uniroma1.it>
> Cc: "'Jacques Durand'" <JDurand@fsw.fujitsu.com>;
> <wsrm@lists.oasis-open.org>
> Sent: Tuesday, September 23, 2003 9:28 AM
> Subject: Re: [wsrm] R: [wsrm] Rel YY
>
>
> > Paulo and Jacques,
> >
> > This appears to be a standard performance / storage trade off.  The
> > direction chosen at our last face to face meeting emphasizes simplicity
> > of the specification and implementations.  The suggestions below
> > optimize on the other side, toward reduced storage requirements.  The
> > included reasoning depends upon the number of messages received overall
> > (in some time period) and how many of those messages come from the same
> > origin.  Without clear numbers applicable to all WS-Reliability use
> > cases (something we are not going to get), I find it hard to choose.
> >
> > Absent concrete numbers, I would probably lean toward the simpler
> > solution already chosen by the group.
> >
> > thanx,
> > doug
> >
> > On 22-Sep-03 16:49, Paolo Romano wrote:
> >
> > > I like Jacques proposal. We should address both the problems of (1)
> > > minimizing the state information that needs to be persistently stored
> > > and of (2) how to efficiently acknowledge batches of messages. The key
> > > idea of Jacques suggestion is to have a sequential, strictly
> > > increasing identifier. Such a property could then be exploited to
> > > record/acknowledge continous sequences of messages (i.e. messages with
> > > sequential MessageIDs) by referincing only the lower and upper bound
of
> > > the sequence.
> > > With this approach, it is possible to reduce the amount of memory
> > > required at the purpose of duplicates elimination even furtherly:in
fact
> > > if, for a given GroupID, a set of messages with
> > > MessageID={0,1,..i..,n-1,n} has been received, then it is only
necessary
> > > to store the MessageID "n", to indicate that messages up to n have
> > > already been received.
> > > As an example, consider a receiver RMP which has caught the messages
> > > carrying GroupID:X and MessageID={1,2,3,4,5,6,10,15,16}. It should
only
> > > record that "messageIDs up to 6" and MessageID={10,15,16} have
> > > been received. In general, if a sequence of
MessageIDs={j,j+1,..,k-1,k}
> > > with k>j is received, it is sufficient to store just j and k. Note
that
> > > this property is independent on having enabled the ordering
> > > functionality at the RMP level.
> > > On the other hand, GroupID is essential (and sufficient) to allow
> > > univoque identification of the "conversation".
> > >
> > > Paolo
> > >
> > >
> > >
> > >
> > >
> > >     Here is a more precise wording of the issue I see with limiting
> > >     the use of sequence numbers to ordering only.
> > >
> > >     Jacques
> > >
> > >
> > >     A new issue, (related to Rel-36, Rel-88)
> > >     ------------
> > >
> > >     Precluding the use of sequence numbers, when message ordering is
NOT
> > >     required,
> > >     will pose serious scalability issues for duplicate elimination
> > >     algorithms.
> > >     Indeed, in doing so the GroupID would actually behave as a Message
> ID,
> > >     and will require to be stored for each past message for the
> > >     duplicate look up.
> > >     Consider the two following deployment cases of WS-R:
> > >
> > >     Case 1: Assume a messaging Hub, that must guarantee exactly once
> > >     delivery under
> > >     the following conditions:
> > >     Throughput: 1000 messages/sec
> > >     Size of GroupID values (approximately): 30 bytes
> > >     Scope of duplicate checks: messages over last 5 days
> > >     Using a messageID-based duplicate check, this Hub must keep a
> > >     database of GroupIDs able to store:
> > >     1000 mesg * 432,000 (Number of seconds in 5 days) = 432,000,000
> > >     GroupIDs to store.
> > >     Database size: 12.9 GB.
> > >     Besides the significant resource investment needed, (which may
> > >     please database vendors!)
> > >     this solution may simply not be feasible or at least cause quite
an
> > >     additional headache and cost:
> > >     the database may not keep up with the speed required for duplicate
> > >     checks:
> > >     fast retrieval would require indexing. But the high rate of
updates
> > >     of such an index
> > >     (2000/sec counting additions and removals) offsets the performance
> > >     gain in indexed search,
> > >     as we know indexes are costly to update, especially on a large
> table.
> > >     One way or the other, the overhead of duplicate checking may
simply
> > >     be overwhelming.
> > >
> > >     Case 2: Assume a messaging end-point, receiving 10 messages/sec
> > >     average.
> > >     Duplicate search is required over the last 30 days. We would still
> need
> > >     a full-fledged database (or B-tree) engine, with data size close
to
> > >     1 GB.
> > >
> > >
> > >     Proposal: (P1 + P2 + P3)
> > >     ---------
> > >
> > >     P1: Make it possible for Senders to use GroupID + SequenceNo to do
> > >     any grouping they want,
> > >     even when ordering is not required. The only requirement is, these
> > >     elements
> > >     should be used as they are for ordering, i.e.:
> > >     - (GroupID + SequenceNo) must be globally unique,
> > >     - the sender must generate contiguous sequence numbers within a
> group.
> > >
> > >     P2:SequenceNo element is mandatory in the header, even when NOT
> > >     requiring ordering.
> > >     In both cases, a Sender can at discretion:
> > >     - (a) send messages with a different GroupID each time (1 message
> > >     per group, with smallest
> > >     SequenceNo)
> > >     - (b) send longer sequences of messages within a group.
> > >
> > >     P3: To signal the Receiver to do ordered delivery on a sequence,
the
> > >     Sender will add
> > >     messageOrder element in the header (close to option (3) in Rel
88),
> > >     and is required to
> > >     do so at least in the first message(s) of a group.
> > >
> > >     NOTE1: On the receiver side, duplicate message elimination would
use
> > >     SequenceNo
> > >     for fast duplicate elimination within a group, and use an indexed
> > >     search over a store
> > >     of GroupIDs for all groups currently active. Clearly, in the
extreme
> > >     case (a) above,
> > >     duplicate elimination would be as costly as over conventional
> > >     message IDs.
> > >     But if Case 1 above actually has only about 1000 "active groups"
at
> > >     any time
> > >     (e.g. 1000 concurrent senders generating each a single long
sequence
> > >     at rate of 1 mesg/sec),
> > >     then the GroupID store and seq number info associated with it, can
> > >     hold in the memory
> > >     of a small device (estimate: 1 Mb) and does not need a DBMS.
> > >
> > >     NOTE2: The requirement (Rel 26) to allow for "multiple-Ack"
> > >     messages, can be fulfilled
> > >     in a simple way when using sequences of messages, by the use of an
> > >     interval notation to signal
> > >     groups of messages that are acknowledged. Or, use an upper bound:
> > >     One Ack message could state
> > >     that all messages below SequenceNo N are acknowledged.
> >
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
>
http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
> >
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]