RE: [wsrm] about ordering

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Title: RE: [wsrm] about ordering

Doug and al:

First, I apologize if some of my comments appear to reopen past issues,
that was not my intent. I know I have missed many past discussions, and
just catching up, (without sounding too uninformed I hope)...

Let me see where that leaves us:

- The tie {ordering + guaranteed delivery} suggests that one ordering
definition is most relevant, the one I call "consecutive ordering"

- This calls for  resolution (a) in Rel 57 in case of - still possible - missing message, ("..abort all further ordering for the group", which i assume means

we don't pass any subsequent message of the group to the application)

- I did not feel however we were adding to the requirements doc, as its definition of
ordering is quite informal and open (unless we make it more precise?).

- As part of resolution of Rel 57, I would suggest that the specification
(if not the requirements doc), makes a clear definition statement for ordering, so that
other incidental mentions of ordering (e.g. in 2.4) will not be mistaken for definitions.
(the closest to the definition we want I believe is found in paragraph #2 in section 3.3.2)

Jacques

-----Original Message-----
From: Doug Bunting [mailto:Doug.Bunting@sun.com]
Sent: Thursday, September 11, 2003 11:36 AM
To: Jacques Durand
Cc: 'wsrm@lists.oasis-open.org'
Subject: Re: [wsrm] about ordering

Jacques,

The rest of this thread seems to be extending the options rather than
addressing the questions you raise so I will start back here.

I do not believe this proposal aligns with the decisions this group has
already made on REL-16 and adds requirements not presently in our
Requirements document.  In a number of previous discussions, we chose
*not* to cover the monitoring (ordered but not guaranteed delivery) use
case.  This proposal appears to head toward reopening those earlier
decisions.

thanx,
        doug

On 08-Sep-03 21:15, Jacques Durand wrote:

> I propose the following (partial) answer for Rel 57, see below,
> and also after this, see my concern on the way we seem to tie the
> "ordering" vs "no ordering" decision
> to the seq number value (section 9.5 in the meeting minutes)
>
> Regards,
>
> jacques
>
> *Rel 57:*
>
> *Proposal*: Message ordering has actually two variants (o1) and (o2)
> that address different ordering requirts. Roughly:
>
>       -       "message ordering" (o1): loosing some messages will not
>       "break" a sequence, provided that what is passed to the receiver
>       application is still ordered. We can imagine that a flow of
>       messages from a monitoring device could just need that.
>
>       -       "consecutive message ordering" (o2) a missing message is
>       not allowed in the delivered sequence. A message that cannot be
>       waited for any longer, should break the sequence, and subsequent
>       messages not be passed to the app (so this enforces passing only
>       consecutively ordered sequences).
>
> The spec seems to endorse either o1 (section 2.4) or o2 (section 3.3.2).
> Instead, it should clearly define these two variants.
>
> *Definition 1*: (message ordering, o1 above):
> When "message ordering" is required, an  RMP implementation that is
> required to do "message ordering" , MUST NOT make any two received
> messages available to the application in a different order than their
> sending order.
>
> *Definition 2*: (consecutive message ordering, o2 above):
> When "consecutive message ordering" is required, an RMP implementation
> MUST enforce "message ordering", and in addition MUST NOT make a
> received message available to the application if its was sent after
> another message that is not yet available to the application.
>
> Depending on which variant is used, o1 or o2, either one or the other of
> the current options (b)and (a) respectively
>  in Rel 57 will apply.
> The decision when to decide to "not wait anymore", remains to be decided
> (TimeToLive of the first unordered message? The min of TimeToLives of
> all unordered messages? Or a max unordered window size parameter,
> related to Rel 56.)
>
> -------------------------------- meeting minutes 9.5:
>
> "...The text is currently unclear on whether sequenceNO other than 0 can
> be used without ordering. The general consensus is no."
>
> *Issue*: restricting the use of sequence numbers to the message ordering
> feature alone - and enforcing one message
> per groupId otherwise, with seq nbr equal to 0 - will preclude
> implementations from using of a whole set of fast and space-efficient
> algorithms for duplicate elimination.
>
> *Proposal*: Do not preclude using sequence numbers for other purpose
> than message ordering, at least until some conclusive results have been
> obtained on testing duplicate elimination algorithms. The spec should
> only require
>
> that (groupId + seq.nbr) be always unique.
> If the concern is about how to instruct an RMP what to do when it sees a
> sequence number in a message (should order? Should not?), that is
> another problem that could be solved separately.
>
> If we resort to such tricks as using a different groupId for each
> message that does not require ordering, this amounts to enforcing
> duplicate check algorithms that are based on unique messageId strings.
> This will lead to more costly duplicate check (less scalable and less
> performant) and to the use of two different algorithms, if we still want
> to use sequence number-based duplicate check for ordered sequence that
> also need exactly once delivery.
>

--
SunNetwork 2003 Conference and Pavilion
"An unparalleled event in network computing! Make the net work for you!"

WHEN:  September 16-18, 2003
WHERE: Moscone Center, San Francisco

For more information or to register for the conference, please visit:
http://www.sun.com/sunnetwork