OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Minutes of 11/04 Teleconference (does not count for voting rights)


the prelim minutes are attached.

I will mark this meeting as not counting towards voting rights.

We need to vote the pending resolutions from the f2f at next week's 
teleconf.

Please post comments, I will still post these minutes to the server.

Tom Rutt
WSRM chair

PS the bridge situation will be sorted out before next call.  Look for a 
message with the proper
bridge number.


-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133


Title: Draft Agenda to WSRM TC Conference Call May 06, 2003

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

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]