Prelim Minutes WSRM TC Conference Call –
Nov
4, 2003
The meeting of the WSRM TC took place by teleconference
Tuesday Nov 4, from 5:30 to 6:30 PM Eastern Standard Time
(UTC - 5)
The call-in details were as follows:
Dial-in numbers:
----------------
Toll Free - : 1-800-605-5167
International - : 1-719-457-0339
Passcode: 732072
0
Draft
Agenda:
Draft Agenda to WSRM TC Conference Call – Nov 04, 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 Approval of
Pending Resolutions
4 Discussions of
Issues
1
Roll
Call
There was a problem with the original conference
bridge.
Not quorate, because
of bridge problem, agreed
that this meeting will not count towards voting rights.
Sunil provided an alternative
|
First
Name
|
Last
Name
|
Email
|
Role
|
Company
|
|
Jeff
|
Turpin
|
jturpin@cyclonecommerce.com
|
Member
|
Cyclone
Commerce
|
|
Pramila
|
Mullan
|
pramila.mullan@rd.francetelecom.com
|
Member
|
France Telecom
|
|
J
|
Durand
|
jdurand@fsw.fujitsu.com
|
Member
|
Fujitsu
|
|
Kazunori
|
Iwasa
|
kiwasa@jp.fujitsu.com
|
Secretary
|
Fujitsu
|
|
Tom
|
Rutt
|
tom@coastin.com
|
TC
Chair
|
Fujitsu
|
|
Robert
|
Freund
|
bob.freund@hitachisoftware.com
|
Member
|
Hitachi
|
|
Eisaku
|
Nishiyama
|
nishiy_e@itg.hitachi.co.jp
|
Member
|
Hitachi
|
|
Nobuyuki
|
Yamamoto
|
no_yama@bisd.hitachi.co.jp
|
Member
|
Hitachi
|
|
John
|
Fuller
|
jfuller@wernervas.com
|
Observer
|
Individual
|
|
Magdolna
|
Gerendai
|
magdolna.gerendai@nokia.com
|
Prosp Member
|
Nokia
|
|
Sunil
|
Kunisetty
|
Sunil.Kunisetty@oracle.com
|
Secretary
|
Oracle
|
|
Doug
|
Bunting
|
doug.bunting@Sun.com
|
Secretary
|
Sun
|
Meeting not quorate.
Agreed to Go until 7 oo,
but not make any motions.
2
Minutes
Discussion
2.1 Appointment
of Minute Taker
Tom Rutt will take
minutes.
No one needed agreed to take issue resolutions.
2.2 Approval
of previous meeting minutes
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/4110/octF2fminutes.htm
Marc Goodner pointed out (by email) :
The resolution for REL-32 in section 14.3 is incorrect. We started with the proposal from Iwasa, but as hinted at in the minutes rather than taking all seven definitions we agreed to only incorporate the first three on the RM-Reply patterns.
The issue resolution however, is properly recorded in the current issues document:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/4115/wsrm-reqm-issues-2003-11-04.html
xx moved to accept the minutes. yy seconded.
.// opposition minutes approved.
3
Approval
of Pending Resolutions
REL-31 Meaning of guarantee
Pending
REL-35 Header
processing order
Pending
REL-38 Timestamp
Pending
REL-75 Meet
Realization, R7.2 (multiple ack) requirement
Pending
Pending Polling
RM-Reply Pattern design
Pending
REL-100 Attachments
Pending
REL-32 Add new terms
from requirments
Pending
REL-34
Figure 4 needs refinement
Pending
Agreed
that we will vote the pending issues at next teleconference meeting.
Look at these and do
comments on mailing list.
4
Discussion
of Issues
4.1 Timing
Issues
Jacques sent an email
with the following indented text.
Comments from meeting discussions are not indented: add list of issues this relates to into
minutes
ExpiryTime:
----------
ExpiryTime indicates the ultimate date after which the
receiver RMP will
NOT
accept a message (see meaning of "accept" in state diagram).
-
An RMP receiving a message after its ExpiryTime date,
MUST NOT accept the message.
-
Once a message is accepted by the RMP, the fact that the message expires while
being processed by the RMP MUST NOT affect its processing,
nor its final availability
status to the receiver application.
NOTE
about the use of ExpiryTime for Duplicate
Elimination:
Although
ExpiryTime will not affect the processing of accepted
messages,
it is useful for an RMP to remember it in order to later
reduce the number of
duplicate checks, when "at most once" delivery is
required.
Given
the above definition of ExpiryTime, it should not be
necessary to compare the ID
of a newly received message with the ID of past expired
messages.
An refinement to this rule is when a message has been
received before its ExpiryTime,
but is expiring before its duplicate check is performed. In
this case an RMP MUST also
extend the duplicate check of this message, with the ID of
some past messages that are
also expired, but were not yet expired at the time the newly
received message had been
moved to "ready" state.
Acknowledgement
semantics:
--------------------------
A
positive acknowledgement is generated when a message has been accepted by the
receiver RMP.
This
means that (1) the RM extensions of the message header were valid, (2) the
message has
not expired, (3) the message was not a duplicate (transition
"accept" to the state "in-process").
The
acknowledgement means to the Sender RMP that its role in the reliability
contract for this
message is over, and that the Receiver RMP has now full
responsibility to satisfy the reliability agreement.
Note
that this does not guarantee that the message will eventually be delivered to
the
receiver application. If any of the three conditions above was not
satisfied, an RM Fault will be generated instead.
Synchronization
Sender-Receiver:
--------------------------------
A
Sender and a
Receiver are synchronized, when they have both the same
awareness of the outcome of a message transaction, i.e.
whether or not the
message was delivered or made available to the receiver
application.
A
Sender and a
Receiver are "failure-synchronized", if they have both
the same awareness of a failed message transaction.
This
specification does not support full synchronization of a Sender and a Receiver,
but provides a reasonable guarantee of
failure-synchronization.
Two
RMPs implementing this specification may not be
synchronized in the following case:
A
message may be sent, received, made available to the receiver application,
but never acknowledged properly even after resending it.
In
which case, the Sender will conclude that the delivery failed, while the
Receiver
knows that the delivery was successful.
Two
RMPs implementing this specification will always be
failure-synchronized:
If
a Receiver fails to deliver a message (invalid, expired, duplicate,
out-of-order)
sufficient notification will be generated to the Sender so
that the Sender can infer
that the delivery failed.
NOTE:
a message may be positively acknowledged, and yet never delivered to the
receiver application, if it has been held by the receiver
RMP as out-of-order
then discarded. In such a case however, a fault would be
generated to notify the Sender
of the delivery failure. It is the absence of such fault,
not just the presence of a
positive Acknowledgement, that allows a Sender to conclude
that a message was
delivered to the receiver application.
Termination
of a group vs. Removal of its state:
-------------------------------------------------
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. (Note that such
a message would never be
delivered to the receiver application if guaranteed ordered
delivery was required,
but may be delivered if not.)
-
Removal of the state of a group, means that all trace of the message IDs (GroupId
and SequenceNumber for all
received messages) is removed, and therefore not available
anymore for duplicate checks.
However,
duplicate checks are still necessary some time after a group terminates.
Next sections establishes the rules for when these two
events should occur.
Discarding an "out-of-order" set of messages, and
failure-termination of an ordered group.
-------------------------------------------------------------------------------------------
In
case a set of messages of the same sequence are held in
"out-of-order" state,
the RMP will need to decide how long these messages should
be held before
being either discarded, or delivered. These messages belong
to a group or sequence
for which ordered delivery, and therefore guaranteed
delivery, were required.
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 MUST be
discarded and not
delivered to the application. An RM Fault will be made
available to the Sender.
Discarding
an out-of-order group occurs in the following cases (d1, d2, d3).
Note
that the ExpiryTime of out-of-order messages will not
intervene in their
discarding, as ExpiryTime only has
meaning for initial acceptance or rejection of
a message.
Case
d1: the group had GroupExpiryTime specified in its
messages.
On
the Receiver side, the out-of-order messages MUST be discarded as soon as this
date
expires, and the group MUST be terminated. Indeed, any
missing message received after
this date, will not be accepted by the RMP (as GroupExpiryTime is always greater than
ExpiryTime of any message in the group), and the group will
never be complete.
On
the Sender side, an RM Fault will warn of the failed sequence.
In
case the Sender must take the initiative to poll for such a fault, it will do
so when:
(1)
GroupExpiryTime is over, and (2) some Acks are still missing.
Once
the Fault has been obtained, the Sender MUST NOT send
further messages for this group,
and MUST communicate instead a delivery failure to its
application.
Case
d2: the group did not have GroupExpiryTime specified,
but had GroupMaxIdleTime.
On
the Receiver side, the out-of-order messages MUST be discarded if this maximum
idle time
from the last received message expires, and the group MUST
be terminated.
On
the Sender side, an RM Fault will warn of the failed sequence.
In
case the Sender must take the initiative to poll for such a fault, it will do
so when:
(1)
GroupMaxIdleTime from the last received Ack is over, and (2) not all Acks
were received.
Once
the Fault has been obtained, the Sender MUST NOT send
further messages for this group,
and MUST communicate instead a delivery failure to its
application.
Case
d3: neither GroupExpiryTime nor GroupMaxIdleTime
were specified for messages
of this group. In this case, any out of order message will
be discarded, and
the group terminated. In order to avoid this situation in
the absence of
termination criteria for the group, a Sender SHOULD always
wait for a message to be
acknowledged, before sending the next message in the
sequence.
NOTE:
the cases above (d1, d2, d3) decide of the discarding of out-of-order messages
of a group, and therefore of the termination of a failed
ordered group.
This
does not mean yet the removal of the group state, as message IDs may still be
needed
for duplicate checks. The rules for group state removal (t1,
t2, t3, t4) are described in
another section.
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 to the application (state:
"available").
The
general rule about message ID persistence, is that an RMP
MUST
persist the ID of a message until the message expires.
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 message ID from the
state of its group, when the message expires.
Duplicate
checks would be made over all past messages for the group, whether expired or
not.
There
is no added cost here, as these IDs are remembered as sequence number
intervals.
The
check will in fact be faster, as not discarding means fewer intervals.
General
rules for terminating a group, 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
needs to be maintained.
Termination
(t1):
Triggering
event: GroupExpiryTime is over.
Receiver
side: The group is immediately terminated, and its state is removed from the
RMP.
No
duplicate check is done against that group ever. If a "late
duplicate" arrives,
it would be automatically rejected due to its ExpiryTime.
Sender
side: The group is immediately terminated, and its state is removed from the
RMP.
Termination
(t2):
Triggering
event: GroupMaxIdleTime is over.
Receiver
side: The group is immediately terminated. But unlike (t1), some of its
past messages may not be expired yet. The RMP will keep the
max of all expiryTimes
of messages received so far for the group.
The
max(ExpiryTime) will
determine the date at which the state of the group is removed.
Sender
side: GroupMaxIdleTime is counted between two sent
messages. If it is over,
the group is immediately terminated, and its state is
removed from the RMP.
Termination
(t3):
Triggering
event: the RMP receives a status="end" message. The group had either GroupExpiryTime or GroupMaxIdleTime
specified.
Note
that this only tells us that "no greater seq
number will be received after", but that late messages may still arrive
for this group.
Subcase t3.1: The group was complete on receiver side.
Receiver
side: The group is immediately 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. If either ordered delivery
or guaranteed delivery was required, all Acks
must have been received.
Then
only the group is terminated.
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 t3.1: The group was complete on receiver side.
Receiver
side: The group is immediately terminated. The date of removal of its state is
based on rules for (t2), using max(ExpiryTime)
of all its messages.
Sender
side: The group is also known to be complete. If either ordered delivery or
guaranteed delivery was required, all Acks must have
been received.
Then
only the group is terminated and its state removed.
Subcase t3.2: The group was not complete on receiver side.
The
group is immediately terminated, and its state is removed from both RMPs.
Jacques raised a high
level comment before the details:
Fujitsu developers
looked at the apparent complexity of time management. They stated : just
get rid of expiry time, group expiry time, and max idle duration. The only purpose is to managed
the space of receiver memory properly.
Tom Rutt
– why get rid of expiryTime, for the reasons already
discussed.
Jacques, All of these
fulfils the same role, how to get rid of useless messages in groups. Assume for now the simplest protocol.
The proposal is to keep
everything around forever. In all cases
we need to deal with resource shortage problems, we need a fault reply when
memory is exhausted.
An implementation would
have to deal with the resources. The
only contract is that it will let the sender know (through fault or error) if
it runs out.
Tom asked about the end
status. Jacques state this can not be
relied on for group termination.
Tom: sender can detect
possible out of order failures by conservative assumptions (i.e. if it did not
get an ack for one message in sequence, it cannot
assume the later ones were delivered.)
Doug stated the bigger
issue is nailing down all the new error conditions we are recognizing.
Message is acked
Doug asked about the
out of resources message. Or the Out of Group error.
Doug: Putting resources
as hidden info in receiver would mean we need additional errors.
Bob: Resource errors
will occur no matter what we do. Use
this as the end case, with policy to help determine normal course.
Tom Rutt,
as Chair, asked why the normal expiry time should be included in this
simplified proposal.
Jacques – the expiry
time is only the criteria for not accepting message for processing. He does not see the need for this, except for
an optimization. Once it is expired we
do not keep it around any more.
Jacques – consider the
fact that the expiry time is always infinite, relying on policy and fault messages
to configure the situations.
Tom: Sender could specify
an explicit message to terminate the group, this could
help the problem of storage.
John Fuller –
Asynchronous service access protocol has a service which has a request to
terminate.
Bob: Given we dump
these timers, the real receiver state required to maintain drops
considerably. For an ordered group we
have all we need to clean up an ordered group.
Tom: add a new status
value – removeGroupState to kill the state
information in the receiver.
Bob: What is semantic
meaning of end status.
Jacques: all this is
for the holding of state information in receiver memory. Group could map at the business level.
Bob: sequence nos are in an unordered group. We could pass a deferred message, with the
group, even though the end element is passed.
Tom asked about
explicit termination of group with an explicit message from sender.
Polling
for faults.
Jacques: policy to get
rid of old state info.
Tom: how to deal Fault
notification: how does the fault info
get to the sender.
Can polling be used to obtain info. Would want to keep this info around long
enough for the sender to poll it.
Meeting closed at 7:00 Eastern time