[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Preliminary minutes 11/11 teleconf
I found some typos.
> No opposition. Rel 31, 35, 58,75, 94,100, 32, 24 are now accepted.
This should be:
> No opposition. Rel 31, 35, 38,75, 94,100, 32, 34 are now accepted.
Changes:
58->38
24->34
Thanks,
Iwasa
----- Original Message -----
From: "Tom Rutt" <tom@coastin.com>
To: "wsrm" <wsrm@lists.oasis-open.org>
Sent: Wednesday, November 12, 2003 9:08 AM
Subject: [wsrm] Preliminary minutes 11/11 teleconf
> The prelim minutes for 11/11 teleconf are attached.
>
> Please post any changes BEFORE Thursday PM of this week.
>
> Tom Rutt
> WSRM chair
>
> --
> ----------------------------------------------------
> Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com
> Tel: +1 732 801 5744 Fax: +1 732 774 5133
>
>
>
----------------------------------------------------------------------------
----
> Draft Agenda to WSRM TC Conference Call ?May 06, 2003Prelim 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-5659International:
1-913 312 4155 Passcodes:----------Participant: 5989970 Draft
Agenda:
> Draft Agenda to WSRM TC Conference Call ?Nov 11, 20031 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 ?ake 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.
>
----------------------------------------------------------------------------
----
> 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.
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]