Full Agenda WSRM TC Conference Call – Dec
02, 2003
The meeting of the WSRM TC took place by teleconference
Tuesday Dec 02, 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
XML 2000 Demo
4 Discussions of
Issues
1
Roll
Call
Meeting ?? quorate.
2
Minutes
Discussion
2.1 Appointment
of Minute Taker
Tom Rutt will take
minutes.
?? will take issue
resolutions.
2.1 Approval
of previous meeting minutes
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/4379/MinutesWSRMTC1125.htm
xx moved to accept the 11/25 minutes. yy seconded.
?? opposition, 11/25 minutes ?approved.
3
Discussion
of XML 2003 Demo
4
Discussion
of Issues
4.1 Rel 52 and 57
The following is an email thread from Tuesday
afternoon:
Jacques Durand wrote:
> Tom: inline <JD>
>
>
> -----Original Message-----
> From: Tom Rutt
[mailto:tom@coastin.com]
> Sent: Tuesday, December 02, 2003 10:22 AM
> To: Sunil Kunisetty
> Cc: Jacques Durand;
'wsrm@lists.oasis-open.org'
> Subject: Re: [wsrm]
Rev "d" of Rel52, 57
>
>
> Sunil Kunisetty
wrote:
>
> > > Jacques,
> >
> > Comments inlined in red.
> >
> I have a few comments:
>
> Asuming we have
the concept of group persistence control as an optional
> protocol feature, under
> control of the
sender, I would like to proposed the following
> assumptions on the
two
> group persistence
control parameters:
>
> a) the First message in a group (the one
with status=start) determines
> whether group pesistence control is in use for the group.
> - If the first message in the sequence of a
group has neither group
> persistence
parameter present, the group state will be removed upon the
> expiry of the last
message received for the group.
>
> <JD> That
seems to contradict termination case t4 in Rel52d proposal
> (is there anything wrong with it?).
>
Sorry, I meant to mean do t4. A group without group termination parameters
still has to reach
a termination criteria
before the group deletion criteria can even be applied.
I attach a new state chart which shows these as
two group states.
>
> I think you are talking of termination of a
group here, not just the removal
> of its state
(message IDs, etc.) which may occur later , due to future dup checks.
> If that is the case, I think that is way
too strong: nothing should prevent a user to use a group
> for sending very
sparse messages, e.g. one every day at noon.
> Yet you may want each message to have ExpiryTime of 30mn, because this is
> the max time a
message should take to be transmitted under good enough conditions
> (if it takes more than 30mn, this is sign
of a bad network, and RMP should reject it, fault it.)
> So all previous messages have expired when
a new one comes in, but that
> is OK, the group should remain active.
> You may want later to terminate the group
with an "end" marker,
> or even let the
group active forever.
> Note that even when you terminate with an
"end", we still need to keep group state
> until the max (ExpiryTime) has expired (not just the last message ExpiryTime)
> ExpiryTime should
remain a notion orthogonal to the spacing between two messages,
> and in my opinion
should not at all decide of the *termination* of a group.
>
>
> - If the first message has only one group
persistence parameter present
> (either GroupExpiryTime,
or groupMaxIdleDuration) then that will be the
> criteria used for
destroying the group state.
>
> <JD> OK.
>
> - If the first message has both group
persistence paramters present then
> both are in use,
and the first to fire will determine when the group
> state is
destroyed.
>
> <JD> We have
to decide whether (a) it is as you describe, or (b) GroupExpiryTime
> takes precedance.
Right now, the way Rel52 proposal is worded, and also
> the way Sunil
understand it, this is (b). But I have no problem accepting(a).
>
If we do not take a) then we might as well not
allow both termination criteria to be present for group. Lets
decide at the meeting.
> b) Subsequent messages in the sequence do
not need to repeat the group
> persistence paramters. The
sender will continue to used the latest
> received value for each parameter to serve
as the triger for destroying
> the group state.
>
> <JD> OK, I think Sunil has worded
this quite well in his previous email.
>
> c) In any subequent
message either of the two (or both) which were
> present in the
first message can be changed by sending a new value. The
> new value for GroupExpiryTime can only be increased, while the new value
> for GroupMaxIdleDuration can be increased or decreased.
> <JD> I think this is beginning to be
too complex and will trigger many tests.
> I thought we agreed at f-2-f that the first
parameter value encountered was the right one,
> and subsequent
messages should either have same, or nothing.
> I think Sunil also interpreted it that way
(see his Monday email)
>
I think that if we have these group termination
parameters, we might as well allow update.
The
attached state machine
shows that this is not a great burden.
Tom Rutt
> The sender will
> know, when the receiver has acked the message which contains new group
> persistence
parameter values present, that the reciever has
knowledge of
> the new
values. If not acked,
the sender can resend the group
> persistence
parameters in a retry or in a subsequent message of the
> sequence.
>
>
>
> I agree with Sunil that we have to agree on these asumptions (such as
> the above) before we can resolve the issue.
>
> Please comment if you do not agree with my
assumptions above as an
> appropriate way
forward.
>
> Tom Rutt
>
> Jacques Durand wrote:
>
> >> inline:Note
that unfortunately, I won't be on the call tomorrow...
> >> will be in a plane at that time :(But will have access to my email
> >> rest of week.Jacques
> >>
> >>
-----Original Message-----
> >>
*From:* Sunil Kunisetty [mailto:Sunil.Kunisetty@oracle.com]
> >>
*Sent:* Monday, December 01, 2003 6:14 PM
> >>
*To:* Jacques Durand
> >>
*Cc:* 'wsrm@lists.oasis-open.org'
> >>
*Subject:* Re: [wsrm] Rev "d" of
Rel52, 57
> >>
>>
> >>
> >> Jacques,
> >>
> >> Few quick comments now. I'll do a
more detailed review tomorrow
> >> morning.
> >>
> >> 1) For Subcase
t4.2, we need to propose the removal criteria. I
> >>
suggest:
> >>
> >> / Subcase
t4.2: The group was not complete on receiving side.
> >>
The group will be removed/
> >>
/ when the max(ExpiryTimes of individual msgs.)
is met./
> >>
[Jacques Durand] Removal of group state is not same as
> >>
termination of the group: not sure which one you describe here. I
> >>
agree that your statement is good for removing the state, but
> >>
only AFTER
the decision to terminate the group has been made
> >>
(which is the main topic of Rel52). But as long as the group has
> >>
not been terminated, we should not even consider removing its
> >> state. And here in t4.2, which
could be an un-ordered group, I
> >>
still do not see any reason to terminate the group: expiration of
> >>
past messages is not a good reason!
> >>
> >
> > My comment was specific to group
removal as you already covered the
> > group termination part
> > for t4.2 in your proposal. yes, group removal kicks in only after
> > group termination.
> >
> >>
>>
> >> 2) Rel 57 is incomplete as
it doesn't consider a case where
> >> out-of-order/missing msgs.
occur with
> >> "status= 'end'" and GroupMaxIdleTime case.
> >>
> >> Instead, we should enhance t5 and
close Rel 57 as 'covered
> >> by Rel 52'.
> >>
[Jacques Durand]
agee, they overlap. Should
be merged.
> >>
> >> 3) Hence, t5
should be clarified & elaborated further.
> >>
> >> Receiving side:
> >> Triggering event for Termination: In
an ordered group, a
> >>
message expires before delivery.
> >> For state removal:
> >> - If the group has a msg. with
status='end', then removal
> >>
criteria as defined in t3 or t4 for
> >> receving
node will apply here also.
> >> - If the group uses GroupExpiryTime, then removal
> >>
criteria as defined in t1 will apply.
> >> - if the group uses GroupMaxIdleTime, then removal
> >>
criteria as defined in t2 will apply.
> >>
> >> Sender Side: A non-acknowledged
message expires on the
> >> Sender side.
> >> For state removal:
> >> - If the group has a msg. with
status='end', then removal
> >>
criteria as defined in t3 or t4 for
> >> receiving node will apply here
also.
> >> - If the group uses GroupExpiryTime, then removal
> >>
criteria as defined in t1 will apply.
> >> - if the group uses GroupMaxIdleTime, then removal
> >>
criteria as defined in t2 will apply.
> >>
[Jacques Durand] looks fine to me..
> >>
> >> 4) We should
also mention the following (I'm not sure whether
> >>
this is covered by this issue or not,
> >> but we should definitely mention the
following). Without
> >>
these conditions & assumptions,
> >> following Rel
52 will be difficult.
> >>
> >> - If the first msg. in a group (the
msg. with
> >>
status='begin' or seq. no = 1) uses GroupExpiryTime,
> >> then subsequent msgs. in that group may or may not have
> >> it. If exists, the value should be
the same.
> >> Subsequent messages in that group
SHOULD not have
> >> GroupMaxIdleTime.
> >>
[Jacques Durand] ok, I guess this "should not" is because
> >>
GroupExpiryTime always prevails.
> >>
> > I believe this is what we finalized to
make it simple.
> >
> >>
>> - If the first
msg. in a group (the msg. with
> >>
status='begin' or seq. no = 1) uses GroupMaxIdleTime,
> >> then subsequent msgs. in that group may or may not have
> >> it.
If exists, the value should be the same.
> >> Subsequent messages in that group
SHOULD not have
> >> GroupExpiryTime.
> >> - All messages in a Group should
have ExpiryTime. If the
> >>
group also uses MaxGroupExpiryTime,
> >> then all individual message's ExpiryTimes should be less
> >> than MaxGroupExpiryTime.
> >>
[Jacques Durand] OK,
but I think the "ExpiryTimes
should be less
> >>
than ..." is actually a "MUST be less", because we count
on this.
> >>
> >
> > yup.. replace shoulds with musts in the
above sentence.
> >
> >>
>> - ExpiryTime and MaxGroupExpiryTime
are absolute timestamps.
> >> - MaxGroupIdleTime
is a relative one.
> >>
> >> Did I get the above correctly? Did I miss any other
> >> assumptions/conditions?
> >> [Jacques Durand] that certainly completes
usefully Rel52, 57.
> >>
> >> -Sunil
> >>
>>
> >> Jacques Durand wrote:
> >>
> >>> >>>
> >>> Rel52 and Rel57 reworded and adjusted to
late comments, (tagged
> >>> "rev d")
> >>> though nothing radical:
> >>>
> >>> - Still makes use of Group termination
timeouts:
> >>> I really find it hard to overload
message ExpiryTime with group
> >>> termination
> >>> semantics: ExpiryTime
is about the delivery cycle for messages,
> >>> which is orthogonal
> >>> to how long a group should be active.
> >>>
> >>> - Agree that ExpiryTime
should be set, as Bob suggested, based
> >>> on expected
> >>> transport performance and network
monitoring (e.g. round-trip
> >>> timing) and should
> >>> normally be opaque to users.
> >>> It is a tuning parameter that says:
"normally the delivery cycle
> >>> (transport + RMPs)
for
> >>> this message should not exceed this time.
If it does, this means
> >>> that the communication
> >>> conditions are too bad for doing reliable
messaging.
> >>> In that case the RMP will not deliver it,
and notify the app
> >>> instead."
> >>>
> >>> - Unlike ExpiryTime,
group termination parameters have an
> >>> application semantics:
> >>> In the same way a reliability QoS associated with a group is
> >>> based on application needs,
> >>> (e.g. ordering), limit on group duration
is also based on
> >>> application profiles:
> >>> some apps will be able to mark the last
message with "end", some
> >>> will not.
> >>> Among these, some will be able to cap the
duration of their
> >>> groups (GroupExpiryTime),
> >>> some will only be able to say what idle
time can safely be
> >>> considered as terminating
> >>> a group (GroupMaxIdleTime).
Finally, some groups are not
> >>> supposed to terminate ever...
> >>> which is fine as long as an implementation
can handle the space
> >>> overhead (group states)
> >>> in case of many of these
> >>>
> >>> - So in Rel52 I still propose the 4
termination cases:
> >>> They may not make for a concise spec, but
they look very
> >>> implementable to
me:
> >>> in all cases, Sender and Receiver can
synchronize group
> >>> termination without
> >>> need of notification (thanks partially to the
Ack semantics
> >>> (Rel33)).
> >>> To me this is by far the most important
enhancement.
> >>>
> >>> Regards,
> >>>
> >>> Jacques
> >>> <<Time-Rel57d.txt>>
<<Time-Rel52d.txt>>
> >>>
>
>>>------------------------------------------------------------------------
> >>>To
unsubscribe from this mailing list (and be removed from the roster of the OASIS
TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>
> >>>
>
>
--------------------------
Proposals From Jacques
mail:
Rel 57: (revision d) Ordering and Missing
Message Behavior
---------------------------------------
Proposal:
[notes from
author:
- We also use GroupMaxIdleTime
-if specified- for terminating an out-of-order sequence.
- Discarding 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. See Rel52
for this.
- The term "delivery" below has
been precisely defined earlier.]
On the Receiver side, as soon as either:
(1) the earliest ExpiryTime of pending (stored) out-of-order messages has
expired, or
(2) GroupMaxIdleTime
has been specified, and has expired,
all the pending and future out-of-order
messages MUST NOT be delivered.
The RMP MUST terminate the out-of-order
group as early as convenient after this date,
and out-of-order messages must be discarded.
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 all retries have
been exhausted, plus a buffer time (e.g. retryinterval).
(2) a message
supposed to be sent or resent, has expired, and therefore will not
be sent.
NOTE: On the Receiver side, out-of-order
messages, although well-received,
will not be delivered and acknowledged before
the sequence is complete, which may
trigger unncessary
resending from the Sender.
The Sender MAY decide to NOT
systematically resend a non-acknowledged message,
in case a previous message in the group has
not yet been acknowledged.
---------------
Rel 52: (revision d)(New
rules for state persistence, also, related "timing issues")
-------
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: When doing duplicate checks for
messages of a group, there is no loss
of performance in checking over all past
message IDs of the group,
whether expired or not. 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, t5) 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 next
layer, 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:
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 terminated, and its
state removed from the RMP when the time elapsed
since the last sent message (including retries)
exceeds GroupMaxIdleTime.
Termination (t3):
----------------
Triggering event: the RMP receives a
status="end" message. The group had either
GroupExpiryTime or GroupMaxIdleTime
specified.
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.
Subcase t3.2: The group was not complete on
receiver side.
Indeed, an "end" status only
tells that "no greater seq number will ever be
received after", but late messages may still
arrive for this group.
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 time 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.
Then the RMP should keep the group active:
this event, by itself, does not cause the
termination of the group.
Termination (t5):
----------------
Triggering event: In an ordered group, a
message expires before delivery:
Either the message expires in an
out-of-order sequence on the Receiver side,
or a non-acknowledged message expires on the
Sender side.
See Rel 57 for
this case.