Preliminary Friday Minutes WSRM Teleconference

May 30, 2003

5 Requirements Issue discussion

5.1 Rel 43 – message status query requirement

The vote from Thursday on the motion

Spec must support ability of sender to ask the receiver if one or more of its sent messages have been received.

Eisaku stated that he changed is vote on Rel 43 to no.

Magdolna joined by conference bridge

Now the vote is:

Scott y, Eisaku n, Venkat y, Jeff y, Pete y, Paolo y, Doug n, Mark n, sunil n, Iwasa n, Payrits y, Dock y, Mark y, Tom a, Alan y, Magdolna y, Yamamoto a

10 yes

5 no

2 abs

Close the issue with new requirement.

5.2 Rel 17 Persistence Requirments Spec Issue

The definition we accepted on Thur of persistent storage is:

Persistent storage: a data storage which retains data even while system power is not available.

Tom R stated that this definition is flawed, and should change “while system power is not available” to through power on / power off cycles”..

Scott stated that we do not need a requirement around persistence.

Dock: can we write this as a higher level requirement, so we do not have to talk about specific physical storage schemes.

Sunil: not talk about persistenct storage issues, talk about behaviour regarding that a message must be persisted, or messageID must be persisted.

Tom Rutt asked if we could define fault messages to cover the cases when persistent ID store or persistent data store is lost.

Jeff stated this fault processing is extremely complicated, and not always feasible.

When would such a fault be used?

What kind of event would trigger this fault message.

Payrits: The implementer can guarantee (unless one or more SLA specified set of failures occurs) that their implementation meets the protocol.

Magdolna state that a business agreement between mobile operators covers static configuration parameters. Dynamic configuration concerns might require negotiation or protocol parameters.

Magdolna - Reliability is not tied just to persistence. She would like to suggest that it is not a good idea to tie reliability to persistence.

Sunil stated that if you can guarantee to the client that you will not crash, you are persistent.

We may only have to define the requirements for persistence of messages and IDs when defining the protocol behavior.

Definition of persistence is SLA dependent.

Spec needs to define responsibility of protocol. Under some crashes the protocol will not work.

Payrits showed some slides, which showed a case of a mobile phone user who is satisfied with the reliability of their battery powered phone, but needs WSRM to ensure reliability with a poor quality communication channel.

Protocol statements regarding time to live need to talk about storing the message.

Regarding duplicate elimination could state the messageID is stored for later comparison with incoming messageIDs.

Payrits: “I am reliable because I am protected from the BAD THINGS which can happen to me”

Sunil: Standards should not define these levels of reliability, this should be left to service level agreements.

Pete: Some of these things are deployment specific, the implementation can be configured.

Rel 30 has a need to determine protocol features supported by each side.

From Thursday discussion, suggested text for the spec:

If persistent storage fails, the receiver can no longer meet the requirements for duplicate elimination and message ordering.

Payrits suggested eliminating the word “persistent” from the above sentence.

Paolo suggested text for the spec:

In order to assure reliable exchange of messages, WSRM protocol relies on data storage. The failures the protocol tolerates strictly depends on data storage specific properties, and is implementation and deployment dependent.

The current spec states:

With Reliable Messaging, the sender is REQUIRED to persist the message until one of the following conditions are met:

· Receipt of an Acknowledgment message from receiver, indicating the message has been successfully delivered.

· All retry attempts have failed, and a delivery failure is reported to the application layer.

· The span of time indicated by the TimeToLive element has expired.

The above text seems appropriate.

However the following text is offensive to some:

The receiver is also REQUIRED to keep the received message in persistent storage to pass the message to the application layer reliably in the event a system failure or server down time occurs. Both sender and receiver MUST behave as if there was no system failure or system down after recovery. For this reason, both sender and receiver MUST use a persistent storage mechanism, e.g, HDD or equivalent nonvolatile storage .

Could change to:

The receiver is Required to persist out of order messages to support ordered delivery.

The receiver is required to persist the messageID to support duplicate elimination.

Potential resolution of Rel 17:

Close issue with resolution:

Spec should not use the term “persistent storage”. Instead, the spec should restrict its statements to requirements for persisting messages or elements from message headers.

In particular, in the existing spec we need to change:

To:

The receiver MUST persist out of order messages to support ordered delivery.

The receiver MUST persist the messageID to support duplicate elimination.

Also change the title of 2.2.3 to “Message Persistence”.

There was unanimous agreement to accepting the above resolution as a pending resolution for Rel 17. We can move from pending to accepted at a future meeting when we are quorate.

5.3 Rel 06 Revisited

Based on the resolution to Rel 17, it was suggested we no longer need a definition for Persistent storage.

Change the pending resolution of Rel 06 to “ do not need a definition for Persistent storage.

No objections, pending resolution is agreed to be changed to eliminate need for persistent storage definition.

5.4 Rel 05 Revisited

We agreed to the following definition on Thursday to be put in the Requirements Doc:

Non destructive crash (failure): Any crash, which does not

compromise the persistent state ( i.e. the state of an application stored

on a persistent storage) of an application.

Payrits suggested to remove the following definition from the requirements document:

Definition of Reliable Messaging: (freely inspired and rearranged from

WS-Glossary of W3C...)

The ability:

1. of the intended receiver of the message to be assured that it receives

and delivers a given message once and only once, i.e. exactly one time.

2. of a sender of a message to be able to determine whether a given

message has been already received by its intended receiver.

3. of a sender to be assured that the messages are received and delivered

by the intended receiver in the same order in which they were sent.

4. of both sender and receiver of a message to carry out (1), (2) and (3)

in the face of inevitable, yet often unpredictable, non-destructive

crashes which are eventually recovered.

And also delete the definition for non-destructive Crash.

No opposition, the pending resolution will be changed, subject to final approval.

5.5 Rel 33 – Semantics of Acknowledgement

Payrits stated this depends on the implementation of the inter-layer system design.

The statements would depend on a model of the inter-layer services.

Sunil: we could pick one of the following triggers for WSRM receiver Sending ack:

Once received

Once received and persisted

When the receiver makes the message available to the WSRM user.

Different implementations have different semantics for ack.

Propose resolution add this statement to the specification somewhere:

Sending an Ack means that the receiver has received the message and made it available to the WSRM user.

No opposition, make this the pending resolution to Rel 33.

6 Next meeting

June 16 and June 30 will be the next two conference calls. It will be posted.

Face to face planned Sept 16 17 and 18, in Boston, to he hosted by MITRE.

There was a general agreement to starting the meeting on Monday.

Two alternatives, Mon thru Wed, or Tue thru Thurs. Discuss on the list.

Meeting adjourned 12:20 PM.

Marc G will post the latest issues list this week.

Payrits will post the latest Requirments Editors Draft sometime next week.

Everyone should comment on the mail list for both the remaining requirements issues and Spec issues.