Preliminary Minutes WSRX TC Face To Face Meeting
(Sep 21, 2005) - PM
-----
10 Wed
PM issue discussion
Decision to advance to i008 before
returning to I009 resolution.
10.1 Issue 008 Policy Assertions Granularity
Tom Rutt summarized that, for
example, the DA assertions might be applied at a level smaller than port type.
Some use cases would benefit by apply
a different DA level to operations within the same Endpoint or port type.
Anish: Some might even go down to message, which is
smaller than Operation.
Paul: it might suffice to just take away the restriction in
the current document. The policy
framework may be allow policy attachments lower than
operation.
Claus: Currently, endpoint, operation, message and service
are the attachment points for ws-policy. The
design of the assertion can put restrictions on where it can be attached. The assertion definition must make it clear at
which point it may be attached. A given
assertion type may only be attached to one point of attachment.
Anish: Do we need to restrict
ourselves to ws-policy as it exists now?. We should look at
what our requirements are, and if ws-policy does not
meet these requirements, the standard process for ws-policy
could change it to meet our requirements.
Tom: The current rm policy
assertion document has endpoint as the only attachment level for rm policy assertions.
Doug D: would removing DAs from the spec simplify the
attachments of policy.
Anish: That would remove many
issues and simplify the spec.
Doug D: not mentioning DA at all in the spec would simplify
the specification. The policy assertion would
simply state (using RM).
Serge: it would be odd to have no place in the WSDL to
indicate what level of reliability is required for the endpoint.
Gil: It seems you have to present a context on what the
protocol is used for.
Doug D: in fact the current protocol does not depend on DA
levels. Removing all mention of DA from
the spec would not change what goes on the wire.
Gil: People have expectations, and the way our DAs are
structured is problematic. We could
break them up on a more refined basis (e.g, duplicate
elimination, ordered delivery, guaranteed delivery).
Jacques: the current spec talks about DA and then protocol
then states that they are orthogonal. Duplicate
elimination is a feature of the contract between rmp
and receiving application. It might be feasible to have a single spec
which only has the protocol.
Vadim: The DA is the only qos
which seems to benefit with a finer granularity than endpoint. The protocol parameters are sufficient to be
specified at Endpoint level.
Anish: I agree that removing DA
from the spec will simplify the protocol description.
Sanjay: I think it might be a loss to take away the
description of DAs.
Anish: the protocol enables DA,
but its description says nothing about it.
We could either remove DAs, or change the protocol to reflect DAs.
Paul C: These DAs are design principles which the protocol
definition was intended to enable. Taking
out DAs or moving them to another document would change them to a “rationale”,
or “design principle” for why the protocol is the way it is. For example the word “index” only occurs in
the sql spec twice, and one is for the “index of
terms” at the end of the spec. I could go either way with Doug D
discussion. In fact the term “at most
once” only occurs once in the spec. It
is a design principle.
Jacques: I like the comparison with SQL. I still would prefer a protocol which can be
flexible enough to refect DAs currently in use at the
receiving end.
Chris F: One concern about removing DA concept, its absence
could raise more questions by people following the progression of the
spec. It would require us to explain something
which is unexplainable. Rather than
purge every mention, we could have an explanation of them as “design principles”
for the protocol. While the protocol does not depend on DA in
use, the DA contract is still important between the RMD and Receiving
application. Being able to advertise
what is going on at an endpoint instance is important. I am kind of torn on this proposal.
Jeff M: People are going to ask “What kinds of assurances
are enabled”. In fact the DAs are
explicitly listed within the scope of the TC.
Sanjay: the definition of message ID increasing by one is
there to enable ordered delivery. Thus
ordered delivery is reflected in the protocol.
Paul F: I agree with Paul C that these are design
principles. The spec would be better to
describe them as that. However, if they
are expressed in policy (as a result of i009) they will also be cast at meta data.
Paul F: we should go back to discussion of I009 since the
only qos which needs granularity less than endpoint
is DA.
10.2Issue 009 Continued
Message was sent out with a proposal by Chris F:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00240.html
<wsrm:DeliveryAssertion mode="[AtLeastOnce|AtMostOnce|ExactlyOnce]"
ordered="[xs:boolean]"? ... >
/wsrm:DeliveryAssertion
A policy assertion that makes a claim as to the delivery assurance policy
observed by the destination endpoint.
/wsrm:DeliveryAssertion/@mode
This required attribute specifies whether or not all of the messages
within an RM Sequence will be delivered by the RM Destination to the
Application Destination, and whether or not duplicate messages will be
delivered.
A value of 'AtMostOnce' means that messages received by the RM Destination
will be delivered to the Application Destination at most once, without
duplication. It is possible that some messages in a sequence may not be
delivered.
A value of 'AtLeastOnce' means that every message received by the RM
Destination will be delivered to the Application Destination. Some
messages may be delivered more than once.
A value of 'ExactlyOnce' means that every message received by the RM
Destination will be delivered to the Application Destination without
duplication.
/wsrm:DeliveryAssertion/@ordered
This attribute, of type xs:boolean, specifies whether, or not, the
destination endpoint ensures that the messages within an RM Sequence will
be processed in order. A value of 'true' indicates that messages will be
processed in order. A value of 'false' makes no claims as to the order of
processing of the messages within a RM Sequence. If omitted, the default
implied value is 'false'.
Tom R: the definition of ordered needs to be change from “processed
in order” to “delivered by RMD to application in order”. The acks will be
sent in the order received, not in the order delivered.
Vadim:
This proposal is between RMD and receiving destination. It does not talk about Source. At most once and at least once do have
implications on the sending side.
Marc G: this is a separate assertion,
it is not yet a parameter of ws rm
policy assertion.
Chris F: it could be a parameter of policy assertion. That is not what we are discussing now.
Claus: requirement for exposing DA on source side should be
discussed.
Serge: Delivery assurance assertions deal with behaviour of destination.
Edits of proposal:
<wsrm:DeliveryAssertion mode="[AtLeastOnce|AtMostOnce|ExactlyOnce]"
ordered="[xs:boolean]"? ... >
/wsrm:DeliveryAssertion
A policy assertion that makes a claim as to the delivery assurance policy
observed by the destination endpoint.
/wsrm:DeliveryAssertion/@mode
This required attribute specifies whether or not all of the messages
within an RM Sequence will be delivered by the RM Destination to the
Application Destination, and whether or not duplicate messages will be
delivered.
A value of 'AtMostOnce' means that messages received by the RM Destination
will be delivered to the Application Destination at most once, without
duplication. It is possible that some messages in a sequence may not be
delivered.
A value of 'AtLeastOnce' means that every message received by the RM
Destination will be delivered to the Application Destination. Some
messages may be delivered more than once.
A value of 'ExactlyOnce' means that every message received by the RM
Destination will be delivered to the Application Destination without
duplication.
/wsrm:DeliveryAssertion/@ordered
This attribute, of type xs:boolean, specifies whether, or not, the
destination endpoint ensures that the messages within an RM Sequence will
be delivered in order, by the RMD to the AD. Order is determined by the value of the RM message number. Ordered delivery would mean that the messages would be delivered in ascending order of the message number value. A value of 'true' indicates that messages will be
delivered in order. A value of 'false' makes no claims as to the order of
delivery of the messages within a RM Sequence. If omitted, the default
implied value is 'false'.
Doug: these delivery assurances are limited in the spec to
the rmd and destination application. Why are we discussing the source.
Paul F: if the source knows that at most once is in use at
the destination, it can decide to throw away messages at the source, before
they are assigned to the sequence.
Tom: given that the protocol requires the RMS always resend
until ack, the sender does not need to know. The only possibility is the
if at most once is in use by the destination, it could decide to not put
a submitted message into a sequence.
Serge: the sender must report not delivery with at least
once, but with at most once it does not have to indicate failure of delivery.
Jacques: the proposed definition of ordered says nothing
about what the sender must do. It does
not state that the sender must always assigning message number in same order.
Tom R: but this is stated elsewhere in the spec. The protocol always requires the sender to
always retransmit until ack, and to send the message
numbers in order. The behaviour of the RMS is brute force to allow any DA to be
met at destination.
Paul F: can you raise this as a new issue?
Umit: section 2.2 already states
this.
Duane N: Services are interfaces. I am fundamentally concerned that we are
violating principles of SOA.
Andreas: we need to change these definitions in the base
spec as well. The two specs need to
agree.
Tom R: we can raise that as another editorial issue later.
Ashok: this is “observed” policy
for the destination endpoint. We need a different word.
Serge: there is no consistency between the main spec and
policy spec, and we are not clear about where it holds.
Paul F: it is clear that these DAs pertain to the
destination endpoint,
We can raise another issue to make the main text agree with these
new definitions.
Marc G: are these parameters of assertions? This must be decided before I want to vote.
Anish: can someone explain what
the difference between parameter and assertion is.
Claus: If this is its own assertion, we need logic or
functionality in place to explain how this assertion is combined with other
assertions. This assertion implies that
the assertion of rm protocol is also made.
Paul F: you could only have this if the rm
protocol is also asserted.
Paul F: we would have to define what happens if the delivery
assurance assertion is made without the rm protocol
use assertion.
Umit: we could allow multiple
assertions, with the source selecting from them. We need to determine if these delivery
assurances are adequate first.
Vadim:
I would prefer a separate assertion, rather than a parameter.
Rebecca: I would prefer small assertions, which are composable.
Marc G: if it is a separate assertion it is not complete,
since we have to define what it means in combination with all other assertions. Is it ok to send DA assertion
without the rm assertion.
Umit: we can accept this text now,
and make decisions on the assertion composition later.
Paul F: we have no motion before the house.
Tom: could we not just state that you can only assert this
if you also assert rm usage.
Paul F: another possibility would be to have this assertion
imply that RM usage is also in use.
Umit: I move we accept this proposed
text to close issue 009 , and we raise a new issue to
decide on whether it is an assertion or a Parameter. Seconded by Chris F.
Doug B: However the new issue resolution should allow changing
the word “assertion” to “parameter”.
Paul C: I move to Table this motion, Marc G seconded.
10 yes
14 no
No abstains.
Vote on motion
18 yes
1 no
8 Abstains
Motion passed.
Doug B: I object to rushing this motion.
Action: Chris F to Raise a new
issue on whether text to resolve issue 9 is to be an assertion or parameter.
Action: Tom to raise a new issue to align the main document
text with resolution to issue 9.
10.3 Return to Issue 008
Tom: R: attaching DA of ordered at most once delivery to the
endpoint, means that for operations which do not
require ordered delivery, the RMD would still buffer their messages at the
destination for ordered delive7r. This
would cause delays in delivery for some operations which are not required, and
excessive usage of buffering resources.
Chris F: I would like to have more email discussion on a
concrete proposal before we discuss this further.
Action: Tom R to submit a concrete proposal for discussion
by the TC members on the email list.
10.4 Discussion of Issue 30
What are the obligations on RMD for use (or not) of Offered
Sequence? core
Description
When an
RMD accepts an offer of a bilateral Sequence, is it Obligated
to use that
Sequence
for response messages to the endpoint that requested creation of the Sequence
in which the offer was made?
Justification
The text in section 3.4 makes no mention of
the obligations, if any that the RMD has
in accepting a CreateSequence with an Offer. The text at 480(pdf) reads:
/wsrm:CreateSequence/wsrm:Offer
This element, if present, enables an RM Source
to offer a corresponding Sequence
for the reliable
exchange of messages transmitted from RM Destination to RM Source.
Origin
Chris
Ferris
Owner
Chris Ferris
Proposal 12005-08-25
As the wsrm:Offer is intended as an
optimization, I believe that the RMD should be
under no obligation to actually use the offered Sequence.
Similarly, I believe that it
should be made clear in the spec that the RMS MUST NOT
presume that the offered Sequence
will actually be used to ensure that there are no interop issues that might arise from one
implementation making such an assumption and another that
chooses not to use the offered
Sequence (for what ever reason). I suppose that we *could*
devise a wsrm:Decline child
of
wsrm:CreateSequence as a courtesy
to the RMS that made the offer so that it could reclaim
the associated resources rather than having to wait until
the offered (but unused) Sequence
expired. That would make it abundantly clear that there was
no association. If we pursued
the wsrm:Decline, then the text
around lines 536-566 will need to be fixed accordingly.
Chris F reviewed the issue and his informal proposal above.
Anish: Another approach would be
to say that semantics of create sequence response without accept element
present, means that the sequence in the opposite direction was declined.
Sanjay asked for a sense of the TC before giving Chris an
Action item to give a refined proposal.
Chris F stated he could write the proposal so it has two
parts, part 1 clarify semantics. Part 2 add decline element.
Action: Chris F to provide a detailed proposal for voting by
the TC.
10.5 Issue 26 Better support in handling space greed
sequences
Description
In case
an RM destination expects a large number of concurrent sequences, it may find
itself
in a position where maintaining the state of existing
sequences takes too much resources. As a
consequence, existing sequences may need to be terminated by
the RM Destination, or new
CreateSequence requests may be turned down, and denial of
service occurs.
COnsider a rate of message loss (and not RM-recovered) of
about one for each million in average,
over a sequence 1 trillion long (about 18,000, 000 times
smaller than allowed maximum).
Representing
the state of such a sequence would require 1M intervals, with about 12 bytes to
code
an interval of (long) integers (long starting number +
length on 4bytes) about 12Mb is used for
the sequence state. For am RM Destination with tens of
thousands of concurrent long-lasting sequences, it means that potentially
terabytes of persistent space will be needed to store the state of these
sequences. Also, the SequenceAcknowledgement element
for such sequences may become extremely bulky (with such a rate loss above,
could reach several Gb once
the sequence gets big.)
Justification
Space
needs over time for sequences states is something unpredictable but manageable,
(somehow like
cache management). If one wants to ensure the scalability of
the RM mechanism, such dynamic
policies as:
* (1) deciding to arbitrarily end some
existing sequence (e.g. LFU)
* (2) dynamically
adjust the maximum sequence length of new sequences at creation time
should be supported (though their specification should
remain out of scope).
For
example, in many cases it is preferable to preventively limit the size of
requested new
sequences, and to decide that below a threshold of available
memory, the maximum length of new
sequences would get smaller. The RM specification is
currently not open to such policies,
mandating a fixed maximum to all sequences created
regardless of resource status.
Related Issues
Origin
Jacques Durand
Owner
Jacques Durand
Proposal 12005-08-09
From
raised issue
(a) create another
fault like "ResourceExhaustion" more
explicit than "SequenceTerminated" fault,
that allows the RM
Source to understand the reason of such an arbitrary termination by the
RM Destination.
*
(b) In addition, if a smaller maximum has been
dynamically decided by the RM Destination,
communicate it to the
RM Source via the CreateSequenceResponse.
Jacques presented the issue and his two proposed solutions.
Anish: Defining a fault makes
sense to me. However I have a question
about the second proposal. If the
destination wants to limit the length of the sequence, most of the time the
limit is on the total size of messages rather than the number of messages.
Chris F: the math assumes persistent gaps that stick around.
With required retransmission the gaps will be filled “soon”. It is not clear we have to maintain a lot of
state with a large sequence. We have a
sequence refused fault, which might be confused with sequence terminated. IBM has hardware to solve the resource
problem.
Tom R: if the rmd runs out of
buffer space for ordered delivery it might want to be able to signal that conditiong.
Paul C: the SequenceTerminated
fault currently implies “unrecoverable condition” as the reason. I do not understand what the sender would use
with this extra information from an additional “resource exhaustion” fault. Cannot this be put the detail element for the
sequence terminated fault.
Chris F: I do not understand why the guy who gets the fault
needs to know why. There is nothing he
can do to fix it. The sequence
terminated fault is used when something bad happens.
Tom: What happens if the sender exceeds the message number
range of the receiving RMP
Chris F: I move to close this issue without change, Abbie seconded.
Chris F: there is a range exceed exception for that case.
No objections to motion.
Resolution: motion passed, issue 26 closed without change.
Paul C: I would like the issue list to point at the minutes
which documented the decision.
Marc G: I usually link the resolution to the Minutes.
ACTION: Marc G will ensure that the issue list contains
pointers to the minutes discussion which carried the
resolution.
10.6 Issue 024 - WS RX policies not manifested on the
wire
Description
Issue i009 asks whether WS-RX should define
policy assertions to define
various kinds of QoS properties for a message sequence. This certainly seems
like a good subject
for discussion. What worries is something related.
There is a tacit assumption that WS-RX
policies will follow WS-Policy
(latest public
version Sept. 2004). This specification
does not state explicitly
how to tell whether a
message conforms to a particular policy.
The assumption is
that one can examine
the headers in the message and tell what policy is being followed.
Thus, the effect of policies is manifested on
the wire.
But neither the suggested QoS
assertions nor the existing WS-RX assertion that
declares the
retry-interval etc. will appear as message headers. So, how do we
tell what policy is
being followed? Clearly, some other mechanism is needed.
One way is for messages to carry the URI of
the policy they adhere to. Another
is to define headers
in the start-sequence and sequence-started messages that
indicate policy
information. I'm sure folks can come up with other good suggestions.
Ashok posted a proposed resolution
at: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00242.html
My concern was that the RM policy assertion was not manifested on the wire
and the current WS-Policy document does not support this.
This afternoon we decided, on issue i009, that the policy was 'observed',
in the sense of wsp:observed that was contained in earlier versions of WS-Policy.
Observed policies are not manifested in messages.
Thus, following this precedence, I suggest we close i024 by saying that:
- The assertion is scoped to the endpoint (this is the status quo)
- The policy is 'observed' - in the sense of wsp:observed
Umit: Is this issue related to
Issue 006, source based qos assertion.. If this is resolved, it would allow a policy
assertion on the wire for the source to indicate to the destination.
Ashok: I am more interested in the
destination to communicate to the source such things as retry interval. I do not think any of these assertions result
in messages on the wire.
Paul F: the policy spec states there should be some message
when policy is changed.
Jeff M: We do not have a standard spec which defines wsp:observed. This may not ever be in the starndard process. I
am concerned about relying on wording in that spec.
Paul F: we can use the word observed, without referring to ws policy spec.
Anish: we could point to the
definition of observed in ws policy. If it changes we would need to change our
spec.
Chris F: I would like to clarify the use of the word
observed in this spec. We have an rm-assertion with properties. Policy is determined based on qname of assertion, not its contents. Policy matching does not look at values. If we want to indicate that a policy parameter
is realized on the wire, we would have to elevate it to a full class assertion
to compose with rm assertion. I would rather we close this and deal with
each individual assertion.
Ashok: I would prefer some
clarifying words in the spec before closing this issue.
Sanjay: I understood this issue to be leading to the sending
of policy parameters on the wire in the createSequence
message.
Ashok: we do not have a strong use
case for this.
Ashok the current spec does not
state how the policy parameters, such as base-retransmission interval, are
communicated from RMD to RMS.
Paul F: I heard that we should have a footnote to define
what “observed” means. We can give this
as an editorial action if we close this issue.
Glen D: I would like to apply these policies on bindings.
Sanjay::binding is an endpoint
policy subject.
Chris F: the question is whether it could be put on a port.
Paul C: it is more appropriate for a Binding.
Ashok moved to Close I 024 with editors
adding clarification to the meaning of “observed”, Abbie
seconded.
Chris F: perhaps we should keep this open so we remember the
concerns.
No objection to adopting motion.
Resolution: Isssue 24 closed with clarification
of meaning of observed to be added to spec.
Action: Ashok to write proposed clarification
text on meaning of “observed” in this spec.
10.7 Issue 25 - form of seqAck when RMD has received no messages
Description
Consider the following scenario: an RMS
establishes a Sequence with CreateSequence
and transmits a
single message that is NOT received by the RMD. It then follows that
with an AckRequested message. What is the correct form of the SequenceAcknowledgement
expected? Should one
be sent?
Justification
The specification and schema require that a SequenceAcknowledgement element
have at least one AcknowledgementRange child element (or a Nack) Yet, MessageNumber
values start at 1 and
increment monotonically by 1 for each successive message in a
Sequence. Zero (0) is
not a valid MessageNumber.
Related Issues
Origin
Chris
Ferris
Owner
Chris Ferris
Proposal 12005-07-20
From raised issue
Recommend that an RMD be required to respond
with a SequenceAcknowledgement element
containing exactly
one AcknowledgementRange child element that has both
the @Upper
and @Lower attributes
each carry a value of "0" to signify that no messages have been
received for a given
Sequence. e.g.
<wsrm:SequenceAcknowledgement
xmlns:wsrm="http://docs.oasis-open.org/whatever">
<wsrm:Identifier>http://example.org/mysequence/1234</wsrm:Identifier>
<wsrm:AcknowledgementRange
Upper="0" Lower="0">
</wsrm:SequenceAcknowledgement>
Chris F gave a summary of the issue. He stated that Doug B provided an alternative
to send empty list.
Paul C: sending “0” seems appropriate in the case of no
received messages, since the source can code easily using a “high water mark”.
Jacques: I prefer the empty sequence case. I do not like reporting invalid sequence
numbers. “0” is not a valid sequence
message number.
Anish: I prefer the empty group of
ranges. I nothing is there, the sender
will not be confused.
Serge: the text states the sequence starts with message number
1, and monotonically increases. The spec
could just state that “0” is used for this special indication.
Paul C: the schema could be changed to put in MinOccurs=0 to cover this case. I could live with this.
Glen D: it is easier to code with minOccurs=0,
rather than using the value “0”.
Glen D moved to close the issue with the Doug B proposal, http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00122.html
using minOccurs=0.
Anish
Seconded.
Chris F: I do not like sending empty things.
Glen D: it causes no problem.
Chris F: I would prefer that we have a complete proposal. We do not have that for the “sending nothing”
approach.
Abbie: I move that we amend the
motion with a replacement motion of Chris F proposal, seconded by Chris F.
Paul C: The prose text has the text “one or more times”. This text needs to say “zero or more times”
Abbie: I want to amend to go with
Chris F proposal.
Straw Poll
Absence – 16
Use value 0 – 17
Too close to call from straw poll.
Jorgen: we have to clarify that we put in 0,0 for the range, and not allow 0 with an upper level in the
range value.
Paul C: we should ask for a straw poll of Cannot live with
empty case, vs not live with 0,0
range case.
Straw poll:
Cannot live with 0,0 - 4
Cannot live with empty ack range –
1
Lei Jin: In current spec the empty ack
range is allowed with Nacks in use. The empty range for no receipt is changing
the semantics. Explicit 0,0 is closer to existing semantics.
Paul F: finding no range currently make one look for NACKS.
Gil: the RMD would be confused in the case of NACKS.
Anish: this semantics could be
clarified.
Tom R: the spec currently claims that the ackRange is optional. It needs to be clarified whether that not
presence implies the use of NACK.
Glen D: I do not like Nack in the
first place. The 0.0 proposal requires
that only one range be included, however it is possible to send further ackRanges which would be erroneous behaviour.
Empty is best ,
but an alternative would be an explicit marker to “nothing received”.
Anish: we could include an
attribute or an element in SequenceAck which
indicates that nothing has been received.
This could not be used with NACK.
Doug B: upper and lower are invalid message numbers, and I would rather not turn an error into a valid
indication.
Jorgen: the rat hole is on the meaning of zero.
Paul F: who agrees with Abbie’s
replacement motion.
12 yes
11 no
4 abstains
Straw poll for using explicit indicator
for no message receipt.
13 yes
10 agains indicator
Jeff moved to table the replacement motion to accept Chris F
proposal to use 0,0 range to indicate no message
received, Glen D seconded.
No objections to tabling.
Action: Anish to propose use of an
explicit marker for NO messages received.
Bob F: we need a persuasive argument, since the issue is so
evenly divided.
11
Discussion of Implementation Subcommittee
Paul F stated SC members should use their SC email list to
discuss three points:
- SC
deliverables
- Interactions
with main TC
- Plan
of action
After agreement the Implementation SC will report their
agreement to the TC as a whole.
Members can add themselves to the SC list directly on
KAVI.