Prelim Minutes WSRM TC Conference Call –
Nov
18, 2003
The meeting of the WSRM TC took place by teleconference
Tuesday Nov 18, from 5:30 to 6:30 PM Eastern Standard Time
(UTC - 5)
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 .9 on Dec 2
4 Discussions of
Issues
1
Roll
Call
|
First
Name
|
Last
Name
|
Email
|
Role
|
Company
|
|
Peter
|
Furniss
|
peter.furniss@choreology.com
|
ProspMember
|
Choreology
Ltd
|
|
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
|
ProspMember
|
Hewlett-Packard
|
|
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
|
|
Junichi
|
Tatemura
|
tatemura@ccrl.sj.nec.com
|
Member
|
NEC
Corporation
|
|
Alan
|
Weissberger
|
ajwdct@technologist.com
|
Member
|
NEC
Corporation
|
|
Magdolna
|
Gerendai
|
magdolna.gerendai@nokia.com
|
ProspMember
|
Nokia
|
|
Sunil
|
Kunisetty
|
Sunil.Kunisetty@oracle.com
|
Secretary
|
Oracle
|
|
marc
|
goodner
|
marc.andrue.goodner@sap.com
|
Secretary
|
SAP
|
|
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
|
Meeting is quorate.
2
Minutes
Discussion
2.1 Appointment
of Minute Taker
Tom Rutt will take
minutes.
Marc G agreed to take issue resolutions.
2.2 Approval
of previous meeting minutes
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/4252/MinutesWSRM%20TC%201111.htm
Bob F moved to accept the 11/11 minutes. Magdolna seconded.
No opposition, 11/11 minutes approved.
3
Discussion
of Vote for .9 CD on Dec 2
We can vote on Dec 2 for an early committee
draft.
The vote can occur at a phone call.
Jacques asked about what would be used for the interop demo.
Bob F stated that they will use the .52 draft
for the demo. The functionality is the same, however there was some renaming of parameters etc.
It was agreed that we should vote the .52 draft.
Bob F: The TC rules state that Electronic voting
must use the electronic ballot system. They also require at least 7 calendar
days for the ballot period..
Doug: Kavi will send
out a notification when the ballot is started.
Bob moved to use electronic ballot to vote 0.52 version in the spec folder as a committee draft. Jacques seconded.
No opposition, Tom will initiate the Kavi ballot on version 0.52 The ballot will close after a ballot
period of 7 calendar days.
4
Discussion
of Issues
4.1 Rel 33
Revisited – Meaning of Ack
Jacques and Sunil proposal:
All:
Sorry for a late notification, but here is a
proposal for Rel 33 where a change in
the current semantics for
Acknowledgements is proposed.
This is in the light of other issues that we are
currently trying
to solve these days.
We would appreciate having at least the
opportunity to present it to the TC at this meeting, if enough time...
Again, apologies for late notice but that is a very recent
conclusion of ours,
and we'd like at least
to get early feedback if possible.
Jacques
-----------------------------------------------------------------
We'd like to propose a change in the semantics
of sending an Acknowledgment.
Instead of sending the Ack
when the message is received, the Ack. would be sent
when the message is
made available to the server-side application/user.
After some discussion related to
faults/notifications, we believe this would help
significantly to get
both Sender/Receiver aligned,
and also reduce the
need for additional faults and notifications, always problematic
(e.g. if polling
needed).
The advantages we see with the new proposal are:
- More consistent semantically because the message
is made available to
the user once acked, no more when buffered.
- Solves the async. failure notification problems.
- Makes Rel 50, Rel 52, and Rel 57 simpler.
- the main difference
is for ordered groups, for pending out-of-order sequence.
- all semantics of RM
features (guaranteed delivery, dup elim, ordering)
would now be
about conditions of
delivery to application.
We have considered cases where Acks of received messages would be delayed
due to out-of-order
sequences (not made available to app yet).
To jot some memories back, this was decision we
made at the first F2F
at Redwood Shores and was reverted back later as it may have payload
affect during retries.
We believe this is a performance issue and
a trade-off on a
functional behavior for a performance one.
Performance can be handled without problem (see
below)
-------- detail:
For implementations that are concerned about
performance hit, an optimization
they could use is to
only retry the lowest un-acked message in a grouped
ordered case, i.e., if msgs. 1,2,3 are sent and Sender
hasn't received
acks.
for 2 and 3, the Sender should not retry 3 until they
get an ack. for 2.
For RMP impl.
that doesn't worry about retries throttling the
Receiver,
they might still send
parallel retries. Either approach won't have any effect
on the end user
behavior.
Rel 33 discussion
Jacques and Sunil email:
All:
Sorry for a late notification, but
here is a proposal for Rel 33 where a change in
the
current semantics for Acknowledgements is proposed.
This is in the light of other
issues that we are currently
trying to solve these days.
We would appreciate having at least
the opportunity to present it to the TC at this meeting, if enough time...
Again, apologies for late notice
but that is a
very recent conclusion of ours,
and we'd
like at least to get early feedback if possible.
Jacques
-----------------------------------------------------------------
We'd like to propose a change in
the semantics of sending an Acknowledgment.
Instead of sending the Ack when the message is received, the Ack.
would be sent
when the
message is made available to the server-side application/user.
After some discussion related to
faults/notifications, we believe this would help
significantly
to get both Sender/Receiver aligned,
and also
reduce the need for additional faults and notifications, always problematic
(e.g. if
polling needed).
The advantages we see with the new
proposal are:
- More consistent semantically
because the message is made available to
the user
once acked, no more when buffered.
- Solves the async.
failure notification problems.
- Makes Rel
50, Rel 52, and Rel 57
simpler.
- the main
difference is for ordered groups, for pending out-of-order sequence.
- all
semantics of RM features (guaranteed delivery, dup elim,
ordering) would now be
about
conditions of delivery to application.
We have considered cases where Acks of received messages would be delayed
due to
out-of-order sequences (not made available to app yet).
To jot some memories back, this was
decision we made at the first F2F
at Redwood
Shores and was reverted back later
as it may have payload
affect
during retries. We believe this is a performance issue and
a
trade-off on a functional behavior for a performance one.
Performance can be handled without
problem (see below)
-------- detail:
For implementations that are concerned
about performance hit, an optimization
they could
use is to only retry the lowest un-acked message in a
grouped
ordered
case, i.e., if msgs. 1,2,3
are sent and Sender hasn't received
acks. for 2 and 3, the
Sender should not retry 3 until they get an ack. for
2.
For RMP impl. that doesn't worry
about retries throttling the Receiver,
they might
still send parallel retries. Either approach won't have any effect
on the end
user behavior.
Pete: The proposal is going back to the original
semantics. We had changed this in a past
meeting.
Jacques: the fault notification mechanism causes problems if
we do not have the semantics.
Original spec was ambiguous.
At Oracle F2f we made it when received.
Now wanting to change back.
Jacques: Sender has a much clearer idea of what is going
on. All our features will key on deliver
to app rather than delivery to RMP.
This removes all ambiguity of ack.
This would make the other timing proposals simpler, since it
takes away the need for fault notifications.
For ordered delivery, the ack would only
happen when the message is actually delivered in order.
Bob F asked what make available to applications means. Are we talking around the “responsibility”
taking issue.
Has it actually received it.
Jacques the RMP is release from any further processing of
this message. Only duplication
elimination must continue once it is made available.
Pete: There could be a queuing or buffer between the RMP and
the receiver.
Bob F: The receiver has received the message, and queued for
delivery, and taken full responsibility, but the app might not yet have
received it. In SNA the actual app did
the sending of the ack.
Jacques: Question also applies for ordered delivery to the
application. At some point we have to
draw a line of what the RMP is responsible for and what the receiver is
responsible for.
Bob F: The RMP should have no further responsibility in
delivering the message.
Peter F: Could it be
store and forward? If so, the receiver
app might not be on-line.
Bob F: Could we state it is in persistent store?
Pete W: That is too strong.
Jacques: assuming a store is too far.
Peter: Could RMP be
store and forward at the application level.
Queuing systems do this al the time.
Can it pass on some of the sequence before the rest? Ordered delivery is only respect to the
actions of the RMP.
Bob F: Ack means transfer of responsibility.
Jacques: The ack is just one aspect of the contract between the RMP and
the receiving application.
Tom: the cell phone contract includes the user keeping the
battery charged to avoid loss of received messages.
Sunil: We never know if something is between the RMP and
user. The ordering case states if all
previous are received, we make the message available
to user. The key point is that we decide
that the ack is on receipt by RMP, or on the RMP
making available to receiver.
Bob F: we have to be careful on the language we use around
“make available to user”.
Sunil: this could be raised as a different issue on the
terms for “make available to user”.
Pete W: we could make
it go away if we define the trigger as “RMP passing responsibility for the
message to the user”.
Iwasa: this will not require a lot
of changes.
Straw poll: opposition to proceeding in this direction.
Peter F: This could
be dangerous. The RMP
and the RM user.
Peter F suggested Delay ack until
the RMP knows that any RM related reasons have been completed, with respect to
its enabling delivery. What is the User?
Sometimes it may not be possible to
have hard line between Reliable message software and its user. The user could be inside the RMP.
Jacques: this goes beyond the ack
problem.
Peter: I am not against it in principle,
we just have to be careful on how we define this semantics.
However the new ack definition has
not yet been incorporated. This will
simplify the proposals, due to the lack of needed notification.
Iwasa: what happens if it is made
available, but the user does not receive it.
Jacques: if the expiry time is changed to the latest time it
is made available to app, this simplifies matters.
Iwasa: Spec does not say what
happens if expiry occurs after the message is made available but before it is
actually received by the user.
Tom: This is dealt with in the contract between the RMP and
its receiving application.
Sunil moved to re-Open Issue 33, Jacques seconded.
No opposition, Issue Rel 33 is
reopened. Editors should point at the
latest mail from Jacques.
4.1
Discussion of Timing Parameters
Jacques: Given that we
have basic agreement on the meaning of ack as
discussed above, we can simplify the resolution proposals for 50, 52, and 57.
Jacques: The semantics of expiry time is the major debate
regarding 50, 52, and 57. We can make
expiry time the latest time we make the message available to the application.
The group did not have time to review Jacques latest email
proposals for Rel 50, 52, and 57.
Jacques agreed to refine his proposal on Rel
50. 52 and 57, to reflect this new direction, of ack
after Responsibility is passed from RMP to user. The group needs to continue discussion on
email.
Bob F: Does this new interpretation of ack
change things enough to remove the timing parameters. The ack is so
conservative that we may not need to have these timing parameters.
Bob F: we are behind schedule, getting to 1.0 soon is still
important.
Tom: We still can keep the same schedule for the public
review, since we have removed the need for an interim .9 CD ballot by our decision
to ballot .52 draft for CD.
Meeting adjourned at 6:30 PM Eastern Time.