Prelim Minutes WSRM TC Conference Call
Nov
11, 2003
The meeting of the WSRM TC took place by teleconference
Tuesday Nov 11, 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 Approval of
Pending Resolutions
4 Discussions of
Issues
1
Roll
Call
|
First
Name
|
Last
Name
|
Email
|
Role
|
Company
|
Voting
Level
|
|
Joseph
|
Chiusano
|
chiusano_joseph@bah.com
|
Member
|
Booz Allen Hamilton
|
1
|
|
Jeff
|
Turpin
|
jturpin@cyclonecommerce.com
|
Member
|
Cyclone
Commerce
|
1
|
|
Pramila
|
Mullan
|
pramila.mullan@rd.francetelecom.com
|
Member
|
France Telecom
|
1
|
|
J
|
Durand
|
jdurand@fsw.fujitsu.com
|
Member
|
Fujitsu
|
1
|
|
Kazunori
|
Iwasa
|
kiwasa@jp.fujitsu.com
|
Secretary
|
Fujitsu
|
1
|
|
Tom
|
Rutt
|
tom@coastin.com
|
TC
Chair
|
Fujitsu
|
1
|
|
Jishnu
|
Mukerji
|
jishnu@hp.com
|
ProspMemb
|
Hewlett-Packard
|
p
|
|
Robert
|
Freund
|
bob.freund@hitachisoftware.com
|
Member
|
Hitachi
|
1
|
|
Eisaku
|
Nishiyama
|
nishiy_e@itg.hitachi.co.jp
|
Member
|
Hitachi
|
1
|
|
Nobuyuki
|
Yamamoto
|
no_yama@bisd.hitachi.co.jp
|
Member
|
Hitachi
|
1
|
|
John
|
Fuller
|
jfuller@wernervas.com
|
Observer
|
Individual
|
observe
|
|
Junichi
|
Tatemura
|
tatemura@ccrl.sj.nec.com
|
Member
|
NEC
Corporation
|
1
|
|
Alan
|
Weissberger
|
ajwdct@technologist.com
|
Member
|
NEC
Corporation
|
1
|
|
Magdolna
|
Gerendai
|
magdolna.gerendai@nokia.com
|
ProspMemb
|
Nokia
|
p
|
|
Szabolcs
|
Payrits
|
Szabolcs.Payrits@nokia.com
|
Secretary
|
Nokia
|
1
|
|
Sunil
|
Kunisetty
|
Sunil.Kunisetty@oracle.com
|
Secretary
|
Oracle
|
1
|
|
marc
|
goodner
|
marc.andrue.goodner@sap.com
|
Secretary
|
SAP
|
1
|
|
Doug
|
Bunting
|
doug.bunting@Sun.com
|
Secretary
|
Sun
Microsystems
|
1
|
|
Tony
|
Graham
|
Tony.Graham@Sun.com
|
ProspMemb
|
Sun
Microsystems
|
p
|
|
Chi-Yuen
|
Ng
|
cyng@csis.hku.hk
|
Member
|
University of Hong Kong
|
1
|
|
Ben
|
Bloch
|
ben_b54@hotmail.com
|
Member
|
Individual
|
1
|
Meeting is quorate.
2
Minutes
Discussion
2.1 Appointment
of Minute Taker
Tom Rutt will take
minutes.
Doug 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
Alan stated we need to add that Bob had asked Alan to produce a white paper for the demo, and Alan agreed to do it.
Alan moved to accept f2f minutes with the above two clarifications, Marc G seconded,
No opposition, October f2f minutes passed.
:
Regarding the 11/04 Minutes:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/4151/MinutesWSRM%20TC%201104.htm
The meeting does not count for voting rights, due to a conference bridge problem which occurred at the last minute. Ben Block reported by email that he Joined the call after the Roll call, since he could not find the new number in time for the roll.
Marc G moved to accept the 11/04 minutes. Bob seconded.
No opposition, 11/04 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
Rel 94 Polling
RM-Reply Pattern design
Pending
REL-100 Attachments
Pending
REL-32 Add new terms from requirements
Pending
REL-34 Figure 4 needs refinement
Pending
Marc g moved to accept all pending resolutions
in the list above, Alan seconded.
No opposition. Rel 31,
35, 58,75, 94,100, 32, 24 are now accepted.
Action: Iwasa will
incorporate resolutions into doc and Sunil will post the resulting schema on
the site.
4
Discussion
of Issues
4.1 Rel 50: Semantics of ExpiryTime:
-------------------------------
Proposal From Jacques:
ExpiryTime indicates
the ultimate date after which the receiver RMP will
not accept a message.
In order to be accepted by an RMP, a message
must have schema-valid
RM headers, and must not have expired.
Only accepted messages are subject to further
processing by the RMP.
When receiving a message after its ExpiryTime date, an RMP MUST NOT accept the message.
Once a message has been 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. Such expired messages must still be delivered to
the application,
assuming they satisfy other reliability requirements.
NOTE:
Although ExpiryTime
will not affect further the processing of accepted messages,
it is useful for an RMP
to remember it in order to avoid unnecessary duplicate checks
with future messages,
when "at most once" delivery is required.
Given the above definition of ExpiryTime, it is impossible that a received message M
accepted by the RMP, is
a duplicate of past messages that are expired at the time M
was accepted.
Sunil raised a concern that the expiry time should
be tied on being made available to user, rather than the last time to be
considered by the RMP.
Sunil asked why not just use group expiry time,
and get rid of expiry time for individual message.
Alan stated the delivery to the app is an
implementation issue.
Sunil stated that we have three drop points:
receipt, made available, taken up by app.
What is the point of just considering transport level.
Ordering is more than transport it is buffering.
Jacques and Alan stated that the contract is
from RMP to RMP.
Bob Freund:
what is the purpose of expiry time?
TCP needs it to put an end to routing loops. In our case, what scenario makes expiry time mandatory.
Jacques expiry time is a transport qos, which the RMP has to honor. Under normal conditions all message should
have arrived by this time limit, if not, the transport is poor enough to
consider the transport no longer valid.
Bob: your sender would know that it did not
arrive if it did not get the ack. How many bricks do we need to build the
house, we do not need to put extra bricks on the house.
Jacques this gives a clear semantic for
duplicate elimination.
Tom asked if we have a requirement in our
requirements spec which led us to having the expiry time be mandatory.
Jacques: expiry time as a transport qos, other case totally eliminate.
Alan qos parm to determine when link is so poor you want to know
it. It indicates there is a severe
problem with end to end path.
Bob but when that problem exists, the lack of acks will let them know.
Alan if there is another way, I would have to
think about it.
Jacques just like we do not have ways to
convey retry count.
Sunil: I do not want to be that drastic, to
necessarily remove. I see not having it
as an extreme fallback case. The
semantics of expiry time change for singleton case and the group case. I have concerns that if the message expiry
time has an impact on the group expiry (T2 in Jacques proposal), it does not
agree with rel 50.
Doug: do you want consistent semantics about
this parameter in all the cases. Sunil
yes.
Jacques the interpretation of expiry time as
being a qos for the RMP can be seen as simplifying
the protocol.
Sunil we need to clarify semantics of expiry
time. Check twice, once when we
receiver, later when we deliver.
Doug my earlier concern on multiple checking
was not for performance, my concern was that the
second check dropping things would lead to the sender not knowing it was
dropped.
Sunil: on sender side, the message should be
kept until is is expired or until all preceding
messages are acked it will not have surprises. This can be enough.
Doug: if message 3 expires before message 2 is
received, message 2 will never be acked. Receiver must be bound to perform the delivery
even if message 3 is expired. It should never check the expiry time after the
first check on input.
Bob in prior protocol work, the only time you
introduce timeouts is when there is no other way out. SNA CICS the app was responsible for providing
the acknowledgement back. Here we have
the RMP, acting as a proxy for the application.
The fundamentals are to get to a fundamental state diagram on what the
reliable transport looks like. We have
to understand from a state table view what this protocol looks at. TCP put timeouts in for router loop
avoidance. We need to get down to a rock
solid spec.
Tom: what about the group state removal based on
a timer.
Bob: if
you have timers, the application designer should be involved. We are getting a message from point A to
point B, and to identify that the receiver has taken responsibility.
Jacques: either use expiry time as transport qos, or not use expiry time at all. We need to continue this discussion on the
mailing list.
Jacques: We need to discuss the deeper meaning
of timing parameters. The RMP needs to
manage state associated with the protocol.
It is part of the protocol.
Bob: we need to ensure we have protocol states
which are fundamental for the operation of the protocol. What does make available to application
really mean.
Jacques like retry interval, and max retry
count, these are part of the protocol, but we do not communicate. Some contracts are rmp
to rmp, others are rmp to
applications. The contract needs to be
clarified.
Jacques, we need a fundamental debate on this
issue.
Bob, there might be reasons, but we have to go
thru the engineering steps to justify their incorporation.
Jacques I had done some work on the management
of these states, and concerns have been raised.
What is the reasonable time for the transport to
do its job.
This will help design the RMP configuration parameters.
Bob: well crafted state diagram will help.
Jacques; I tried this in the past,
we can try again on email.
4.1 Rel 52: (New rules for persistence)(also,
related "timing issues")
-------
Proposal from Jacques:
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: ExpiryTime
does not have any impact on the processing of a received message,
once accepted by the
RMP.
Q3: Within what window will a duplicate be
detected?
[Short Answer:] duplicates will be detected over
all past non-expired messages.
Since by definition, messages that are expired
when received will be rejected, there is
no risk ever to deliver
two duplicates to the receiver application, as long as the ID of
non-expired messages
(or ID intervals in the case of sequences) can be held in persistent store.
[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 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 ID of a message that
belongs to a
non-singleton group, when the message expires.
NOTE: Duplicate checks would be made over all
past messages of 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, 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
needs to be maintained.
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.
- Removal of the state of a group occurs either
at termination time or later.
It means that all traces of the group (groupId, current sequence number, as well as
all received message
IDs for the group as SequenceNumber intervals) are
removed,
and therefore not
available anymore for duplicate checks.
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, always
earlier than GroupExpiryTime.
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 in
the group.
The max(all 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.
There was no time to discuss Jacques proposal
above.
4.2 Rel 57: Ordering and Missing Message Behavior
---------------------------------------
Proposal from Jacques:
[short answer]:
the RMP will wait until
the sequence expires (indicated either by GroupExpiryTime,
or by MaxGroupIdleTime). All out-of-order messages will be then
discarded.
However, even so storage resources may be
insufficient to persist further out-of-order
messages. In that case,
a resource fault (Fault code: "MessageStoreOverflow"
will be
generated and made
available to the Sender.
[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 MUST be discarded and not
delivered to the
application.
Discarding an out-of-order group occurs in the
following cases (d1, d2, d3):
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,
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.
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 immediately terminated.
NOTE: In order to avoid this situation, a Sender
SHOULD either use time-based termination
criteria (like in d1,
d2), or if not, SHOULD always wait for a message to be acknowledged,
before sending the next
message in the sequence.
Tom: why not just send a fault for the out of
order message, and still accept the earlier one when it comes.
Jacques; we should take this to the email for
debate, for we do not have enough time.
In all cases (d1, d2, d3), the Receiver RMP MUST
generate an RM Fault "OutOfOrderSequenceExpired".
In case the Sender must take the initiative to
poll for such a fault, it SHOULD do so when:
(1) some Acks are missing, (2) the group has expired according to GroupMaxIdleTime
or GroupExpiryTime,
if these are specified.
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.
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.