Prelim Minutes WSRM TC Conference Call –
Nov
25, 2003
The meeting of the WSRM TC took place by teleconference
Tuesday Nov 25, from 5:30 to 6:30 PM Eastern Standard Time
(UTC - 5)
WSRM Meeting - Conference call Dial-in numbers:
Toll Free: 1-800-361-5659
International: 1-913 312 4155
Passcodes:
----------
Participant: 598997
0
Draft
Agenda:
Draft Agenda to WSRM TC Conference Call – Nov 11, 2003
1 Roll Call (late
arrival no longer counts by OASIS rules)
2 Minutes
Discussion
2.1 Appointment
of Minute Taker
2.2 Approval of
previous meeting minutes
3 Discussion of
Vote for CD .52
4 Discussions of
Issues
1
Roll
Call
|
First
Name
|
Last
Name
|
Email
|
Role
|
Company
|
|
Joseph
|
Chiusano
|
chiusano_joseph@bah.com
|
Member
|
Booz Allen Hamilton
|
|
Jeff
|
Turpin
|
jturpin@cyclonecommerce.com
|
Member
|
Cyclone
Commerce
|
|
J
|
Durand
|
jdurand@fsw.fujitsu.com
|
Member
|
Fujitsu
|
|
Kazunori
|
Iwasa
|
kiwasa@jp.fujitsu.com
|
Secretary
|
Fujitsu
|
|
Tom
|
Rutt
|
tom@coastin.com
|
TC
Chair
|
Fujitsu
|
|
Jishnu
|
Mukerji
|
jishnu@hp.com
|
Member
|
Hewlett-Packard
|
|
Robert
|
Freund
|
bob.freund@hitachisoftware.com
|
Member
|
Hitachi
|
|
Nobuyuki
|
Yamamoto
|
no_yama@bisd.hitachi.co.jp
|
Member
|
Hitachi
|
|
John
|
Fuller
|
jfuller@wernervas.com
|
Observer
|
Individual
|
|
Junichi
|
Tatemura
|
tatemura@ccrl.sj.nec.com
|
Member
|
NEC
Corporation
|
|
Magdolna
|
Gerendai
|
magdolna.gerendai@nokia.com
|
Prosp Member
|
Nokia
|
|
Sunil
|
Kunisetty
|
Sunil.Kunisetty@oracle.com
|
Secretary
|
Oracle
|
|
jeff
|
mischkinsky
|
jeff.mischkinsky@oracle.com
|
Member
|
Oracle
|
|
Pete
|
Wenzel
|
pete@seebeyond.com
|
Member
|
SeeBeyond
|
|
Doug
|
Bunting
|
doug.bunting@Sun.com
|
Secretary
|
Sun
Microsystems
|
|
Tony
|
Graham
|
Tony.Graham@Sun.com
|
Member
|
Sun
Microsystems
|
|
Chi-Yuen
|
Ng
|
cyng@csis.hku.hk
|
Member
|
University of Hong Kong
|
Meeting is quorate.
2
Minutes
Discussion
2.1 Appointment
of Minute Taker
Tom Rutt will take
minutes.
Minutes need to serve as the only outputs.
2.2 Approval
of previous meeting minutes
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/4315/MinutesWSRM1118.htm
Jishnu moved to accept the 11/18 minutes. Sunil seconded.
No opposition, 11/18 minutes approved.
3
Discussion
of Vote for .52 CD
82% of voting members has responded yes.
We will have a committee a CD at 7:00 Pm.
The reason was to legitimize the demo.
Sunil stated he did not want a public
announcement.
The demo will serve as the publicity.
Keep inside committee.
After the vote, Iwasa
will take document, and change the name to committee draft .52.
4
Discussion
of Issues
4.1 Rel 33
Jacques new proposal from email:
My proposal for Rel33:
- We need first to define "delivery"
of a message (also needed for other RM features):
"action of transferring
the responsibility to process further a message,
from the RMP and onto
the next processor entity. This action marks
the end of the RMP processing
for this message. The time at which this action
occurs must be clearly identifiable
so that the next message processor
can always establish in
which order two deliveries are made.
Examples of delivery are: pushing the message in
a queue accessible by an application,
calling back an
application component, storing the message in a database where
it is accessible by the
next processor."
Then the Ack semantics
is simply:
"An acknowledgement is sent for a message
or made available to its Sender
after the delivery action
is successful and complete for this message."
So its aligned with (4)
from Sunil below:
-------------------------------------------
1) "make it
available to the application/user".
2) "make it
available to the next layer".
3) "RMP passing responsibility for the
message to the user"
[I copied this from the Tom's meeting minutes as
Pete W. saying so]
4) "Transferring the responsibility to the
next layer".
[i
vaguely recollect someone saying it in the call.]
Jacques
Sunil stated he is happy with it.
Jacques moved to accept this proposal, above to
resolve Rel 33. Sunil seconded.
No opposition motion passes.
4.1 Rel 50: Semantics of ExpiryTime:
Jacques email (with edits from discussions):
Rel 50: (solution c)
Semantics of ExpiryTime:
-------------------------------
Proposal:
ExpiryTime indicates
the ultimate date after which the receiver RMP MUST
NOT deliver a received message to the
application.
After a message has been sent for the first
time, ExpiryTime in a message
MUST NOT be modified in any case by the Sender,
when resending the message:
two messages with same
ID (duplicates) MUST have same ExpiryTime.
When a message expires on the Sender side before
being sucessfully sent,
a Sender RMP MUST NOT
send it or resend it, and must communicate a delivery failure
to the Sender
application.
NOTES:
- Given the above definition of ExpiryTime, in case duplicate elimination is required,
when a received message
is processed, it is sufficient to only check for its duplicates
among IDs of past
messages that have not expired yet at the time of the duplicate check.
Jacques moved to resolve issue Rel 50 with the above proposal. Sunil seconded.
No opposition, motion passes.
4.2 Rel 52: (New rules for persistence)(also,
related "timing issues")
Jacques Email from Nov 20:
Rel 52: (Solution c)(New rules for persistence, also, related "timing
issues")
-------
Proposal:
Q1: When can a recipient "forget"
about a sequence?
How long must an out-of-order message be stored
prior to giving up on
ever delivering it to
the application?
Answer: see Rel57.
Q2: How do these time windows relate to the TTL
(expiration) of an individual message?
Answer: see Rel50 and Rel57.
Q3: Within what window will a duplicate be
detected?
[Short Answer:] duplicates will be detected over
all non-expired messages.
Since by definition, messages that are expired
before the RMP processing is over
will not be made
available to the application, and because ExpiryTime
is identical across
duplicates, there is no
risk ever to deliver two duplicates to the receiver application,
when restricting the
duplicate check over the IDs of non-expired messages.
[Long answer]:
General rule for persisting
the ID of a message:
---------------------------------------------
The duplicate elimination feature requires persisting the message ID
(GroupId and
optionally the Sequence Number), after the message
has been processed and
delivered (made available) to the application.
The general rule about message ID persistence,
is that an RMP
MUST persist the ID of a message at least until
the message expires
regardless whether the
message has been delivered or not to the application.
It is RECOMMENDED that an RMP removes the ID of
a singleton message
(message with GroupId but no SequenceNumber)
from its persistent store after it expires.
However, unlike for singletons, it is
RECOMMENDED to NOT remove the ID of a message that
belongs to a
non-singleton group, when the message expires. The reason is, message IDs
for groups can be
stored efficiently as intervals of integers.
NOTE: For groups, duplicate checks may be made
over all past messages of the group,
whether expired or not,
without loss of performance. The check will in fact be faster,
because not discarding
expired IDs means fewer intervals to look up.
General rules for terminating a group, and for
removing the state of a group:
-----------------------------------------------------------------
NOTE: these termination rules apply to both
ordered and unordered groups.
NOTE: In all termination cases (t1, t2, t3, t4)
below, it is not necessary to remember
the ExpiryTime
of all messages of a group, as only the maximum of all ExpiryTime
values
is needed.
NOTE:Termination
of a group, and removal of its state are two distinct events.
- When a group terminates, both in sender and
receiver, no message is expected to be
sent or received for
this group anymore. If a message is received after the
termination of a group,
with same GroupId as the terminated group, it is
considered
by the Receiver as
belonging to a new group (the Receiver is not required
to verify that a new GroupId value has not already been used in a previous
group,
as this test is
impractical).
- When the state of a group is removed, any
trace of the group (including status, groupId,
current sequence
number, as well as all received message IDs for the group
e.g. SequenceNumber intervals) are removed, and therefore not
available anymore for
duplicate checks. State
removal may occur either at termination time or later,
depending on the
following rules.
Termination (t1):
Triggering event: GroupExpiryTime
is over.
Receiver side: The RMP MUST NOT accept any new
message for this group and MUST
terminate the group. It
is RECOMMENDED that its state be removed as soon as possible.
No duplicate check needs to be done against that
group ever. If a "late duplicate" arrives,
it would never be
delivered to the application, as its ExpiryTime,
which is always earlier
than GroupExpiryTime, would have expired.
Sender side: The group MUST be terminated, and
its state removed from the RMP.
Termination (t2):
Triggering event: GroupMaxIdleTime
is over.
Receiver side: Except for an ordered group that
is out-of-order (see this case in Rel52),
the group MUST be
terminated. But unlike (t1), some of its
past messages may not
have expired yet, and therefore their ID still be needed
for duplicate checks.
If we define max(all ExpiryTime)
as the max of all ExpiryTimes
of messages already
received for a group, an RMP MUST persist the state of a group
even after termination
of the group, at least until max(all ExpiryTime), in
case
duplicate elimination
is required.
Sender side: The group MUST be immediately
terminated, and its state is removed from the RMP
when either (1) the
time elapsed since the last sent message (including retries) exceeds
GroupMaxIdleTime, or
(2) for an ordered group, a message has failed to be successfully
delivered (as described
in Rel 57), whichever occurs first.
Termination (t3):
Triggering event: the RMP receives a
status="end" message. The group had either
GroupExpiryTime or GroupMaxIdleTime specified.
Note that such an event only tells that "no
greater seq number will ever be received after",
but late messages may
still arrive for this group.
Subcase t3.1: The
group was complete on receiver side.
Receiver side: The group MUST be terminated.
However, its state is removed according to (t1)
or (t2), depending which termination
criterion was given.
Sender side: The group is also known to be
complete, and MUST be terminated.
However, if guaranteed delivery was required,
all sent messages must either have been
acknowledged, or been
faulted, before termination.
Subcase t3.2: The
group was not complete on receiver side.
Then the receiver RMP and sender RMP MUST apply
rules of (t1) or (t2), depending which one
of GroupExpiryTime
or GroupMaxIdleTime was specified.
Termination (t4):
Triggering event: the RMP receives a
status="end" message. The group had neither
GroupExpiryTime
nor GroupMaxIdleTime specified.
Subcase t4.1: The
group was complete on receiver side.
Receiver side: The group MUST be terminated. The
date of removal of its state
is based on rules for
(t2).
Sender side: see subcase
t3.1 above.
Subcase t4.2: The
group was not complete on receiver side.
This event, by itself, does not cause the
termination of the group.
There was no time to discuss the details of this
proposal. It is left for further email discussion
on how many parameters are required.
4.3 Rel 57: Ordering and Missing Message Behavior
Jacques mail from Nov 20::
Rel 57: (Solution c)
Ordering and Missing Message Behavior
---------------------------------------
Proposal:
[short answer]:
the RMP will wait until
expiration of the earliest ExpiryTime of the
out-of-order messages.
All subsequent out-of-order messages will then be discarded.
However, a shortage in storage resources may
lead to discard out-of-order
messages before the
group terminates.
[long answer]:
Given the definition of Guaranteed Ordered
Delivery, a message must not be delivered
to the receiver
application if not all previous messages were.
Therefore in case a Receiver RMP decides to not
wait any longer for a missing
message, the already
received out-of-order messages for the group MUST not be delivered
to the application, and
can be discarded.
[NOTE 1: we could have discarded only the
"subsequent" messages - i.e. with greater
seq
numbers than the one expired. Indeed, "previous" out-of-order
messages still have
a chance to be
delivered to the app when the missing message arrives,
but the group is broken
anyway, and future messages will not be accepted.
In addition, the fact that a pending message
expires makes it likely that the
missing message also
expires soon. So there is little benefit in keeping the prior
messages to the expired
one. In addition, that makes the RMP implementation more complex.]
On the Receiver side, as soon as the earliest ExpiryTime of pending (stored)
out-of-order messages
has expired, all the pending and future out-of-order messages,
MUST not be delivered to the
application.
The RMP MUST terminate the out-of-order group as
early as convenient after this date,
and out-of-order
messages must be discarded.
(see Rel 52 for definition of group temination)
When sending messages for an ordered group, the
Receiver MAY decide to NOT resend a
non-acknowledged
message before all the previous messages with smaller sequence numbers
have been acknowledged.
It MAY also decide to resend a non-acknowledged message
only when the total
number of non-acknowledged messages is below a threshold that
is implementation
dependent.
On the Sender side, the RMP MUST terminate an
ordered group as early as possible after
one of these events
occurs, whichever comes first:
(1) a message for the
group has not been acknowledged after the last retry plus a
buffer time (e.g. retryinterval).
(2)the ExpiryTime of a message to be sent or resent for the group,
has expired before
the message has been
acknowledged.
Deciding that a message has "Not been
acknowledged" must require a failed poll request
from the Sender, in
case the reply pattern is "poll", or must exhaust the expected
delay in receiving a
multiple-acknowledgement.
NOTE 2: discarding of out-of-order messages of a
group, and more generally terminating a
group, does not mean
yet the removal of the group state, as message IDs may still
be needed for duplicate
checks.
Sunil: The decision of discard out of order
sequence is only using the expiry time of individual messages.
This is not the only criteria to end sequence of
group. The group expiry time can occur
while out of order sequence is waiting.
Jacques, if expiry time is earlier of group,
then the only problem is for group max idle time.
Rel 57 might need a
bit more work.
Bob F: this wording made expiry time the
dominant parameter for storage. If we
are going to be throwing things ouf for expiry time,
what would the group expiry time add.
Max Idle time: message waiting with expiry
before max idle, can end up with same conundrum, max idle must
Be set that none expires while the idle time is
being waited for.
Bob F: Consider, utilize only expiry times for
the management of groups.
Tom R: Is there a requirement for the additional
control of max Idle or group expiry
Doug B: I am having trouble understanding. I have trouble with a gap between messages resulting
in error. We have a general problem if, we
allow the sender to stop retrying after the first attempt, the sender could think
the messages are lost when they have made it to the other end.
Jacques, in control of receiver, but not acked, the sender is in the dark on out of order messages. This is not an issue, the first missing message
has not been acked, that is why the sequence is out of order, all the subsequent
might or might not have arrived. The sender
must assume that all are lost. However it
should resend the first message until it is acked. There is a caveat on that,
always possible message has been delivered while the sender has not received ack.
It is always possible that a message has been well
received, but the sender has not been acked.
A more serious misunderstanding, which we can prevent,
is that they think it has been delivered but in fact it has not been delivered.
Doug has problem why anyone can discern between lost
message and lost ack. Sender must behave as if it has not happened.
Jacques: agree sender should consider message as
lost. However it as received before, the
protocol should work.
Tom: the use of expiry time only, would require that
it be monotonic. This was considered to be
too strong.
Bob F : conditions. If we did not have messageExpiry,
but only group expiry this has problem. The
problem with setting group expiry time for an idle interval,
is that these time depend on what the message expiry time is. The cases of one greater than
another is on case. Other errors and complexity are added by each parameter.
Jacques: I
wish we could make bare boned simple. Expiry
time at message level is needed. However,
a group is open, an rmp has to
manage state for this group. If the group
is not active for a long time, you still have to decide when to get rid of the group.
Bob F: why to we need to retain group state.
Jacques. We
need for duplicate elimination.
Tom: should we add a new enum
to the status for the group: “destroy group”.
Rell 52 and Rel 57 are too new to vote on.
How many parameters do we really need.
We need expiry time for each message.
Do we need other group parameters, to simplify matters
(e.g. to not require imposing monotonic expiry time)
We are making assumptions, I would like to keep it
open as much as possible.
Jacques. If the user does not specify any of these
parameters, they must use the end to stop the group. This needs more discussion.
---------------------------------------