[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of 11/03 teleconf
Prelim minutes are attached. Please provide corrections to the entire list before monday. Tom RuttTitle: Preliminary Minutes WSRX TC Teleconf
Preliminary Minutes WSRX TC Teleconf Nov 03, 2005 – Tom Rutt agreed to take the minutes. 1 Roll CallFrom Kavi, Meeting is Quorate 2 Review and approve of Agenda1) Roll Call 2) Review and approval of this
agenda 3) Approval of the previous meeting
minutes http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15110/MinutesWSRX-102705.htm 4) Administrative Issues Status of CD posting and stable
URLs Attendance ballot for Sunnyvale F2F 5) AI Review http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php 6) New issues since last conf-call http://lists.oasis-open.org/archives/ws-rx/200511/msg00057.html 7) Issue Discussion: Note new stable URL:
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml (Thanks to Paul Cotton for proposal
analysis) ------------------------- i022 Vikas Deolaliker RM Policy Assertion Model's Base Retransmission Interval Clarification Needed i023 Marc Goodner Robust recovery from low-resource conditions http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i023 i054 Umit Yalcinalp Target of
RM Assertion parameters are confusing with respect to how they are specified i055 Marc Goodner Whose Inactivity Timeout is it anyway? http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i055 i056 Chris Ferris How can RMS communicate
the Base Retransmission Interval, Exponential Backoff
and Inactivity Timeout values? http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i056 i006 Tom Rutt Source based delivery QoS policy assertion i050 Marc Goodner spec talks about delivery assurances but does
not clearly relate them to the protocol 8) Any other business Issue 006 was removed from agenda Marc G wanted to add issue 55 for discussion. Paul F stated that people did not have time to prepare for it so it should be referred to next week. Paul C asked for an estimate as to when people will be ready to discuss this. Umit: Is this really a pressing issue? Marc G: we have done research, and are ready to bring it to discussion. Umit: I would prefer more time. I would prefer it not to be next week either, since I am out of time. How about two weeks from now. Agreed to put 55 on agenda in two weeks time. Bob F: The most recent proposal for my issue is not in the agenda. I will post it. 1 Approval of Oct 27 meeting minuteshttp://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15110/MinutesWSRX-102705.htm Tom R moved, Rebecca seconded to approve the Minutes of Oct 27 meeting. Paul C: the section in the minutes do not reflect the difference in document name and namespace. Tom: the minutes might be a little unclear, but an editor’s group was tasked to come up with a complete proposal. § No objection, Minutes of Oct 27 meeting Approved. 2 Administrative Issues2.1 Status of CD posting and stable URLsGil: The CDs were posted yesterday. Tom Rutt added the links to the posted CDs to the TC home page. Tom Rutt pointed out that the document identifier on the cover page is not yet qualified with the tc shorthand prefix. It was pointed out that this needs to be resolved as part of the task that the editors have to come up with a complete proposal on the wsrx prefix for namespaces. Paul C: there are several editorial issues with the doc. Paul C: the action item on wsrx prefix needs to be changed to include document ids. Paul C: I will bring my concerns up as new editorial issues on the email.. OASIS has a guidelines for CDs. The Editors will bring these into their action on namespaces and document identifiers. Agreed to leave the CDs posted as they are now. Sanjay: can we leave CD01 as they are now, with Paul C new issues to be resolved in next editor’s draft. Agreed. 2.2 Attendance ballot for Sunnyvale F2FA Significant number of voting members did not respond. Paul F suggested Members send a note to the chairs, if they did not already post to the ballot. Action: Need a bridge for the Sunnyvale F2F. 3 AI Reviewhttp://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php #0012: Chair took an action item to get a ruling from Jamie
on CVS repository usage. Owner: Paul Fremantle Status: Closed - Editors can survive without CVS. Assigned: 2005-07-17 Due: --- -------------------------------------------------------------------------------- #0031: Open two issues around cancel / fill proposal and use
cases Owner: Stefan Batres Status: Still Open Assigned: 2005-09-21 Due: 2005-09-29 -------------------------------------------------------------------------------- #0051: Sanjay will work with editors to propose a new issue
on the topic of using TC name in all document namespaces Owner: Sanjay Patil Status: Open with modification - action to also include document
identifiers Assigned: 2005-10-31 Due: --- 4 New Issues since last con callhttp://lists.oasis-open.org/archives/ws-rx/200511/msg00057.html
4.1 Proposed-01Title: SeqAck - None and Final Description:
In [1] current schema and pseudo schema doesn't allow None
and Final on the same SeqAck - and they should be. Justification:
Its possible that a sequence could be closed w/o any Acks. Target:
core Proposal:
Make schema and pseudo schema support None and Final -
like this: <wsrm:SequenceAcknowledgement
...> <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>
[ [ <wsrm:AcknowledgementRange
...
Upper="xs:unsignedLong"
Lower="xs:unsignedLong"/>
*
| <wsrm:None/> ]
<wsrm:Final/> ?
| <wsrm:Nack> xs:unsignedLong </wsrm:Nack>
+ ]
... </wsrm:SequenceAcknowledgement> Note:
changed the + to a * on the AckRange element. since Final can appear w/o any AckRanges.
[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf Agreed to accept proposed 01 as new issue.
– owner Doug D 4.2
Proposed-02
Title:
Create Sequence Refused Fault is too restrictive Description:
In WS-RM specification[1], the Create Sequence Refused
fault requires [Detail] to be empty (lines 836-842) as follows: { 4.7 Create
Sequence Refused This fault
is sent in response to a create sequence request that cannot be satisfied. Properties:
[Code]
Sender [Subcode] wsrm:CreateSequenceRefused
[Reason]
The create sequence request has been refused by the RM Destination. [Detail]
empty } We think
that this is too restrictive and should allow any content to be part of
[Detail]. The specification should not dictate interpretation of content of the
[Detail], but should not restrict its contents. Justification:
There may be many reasons to indicate why Create Sequence may be refused by
RMD. Further, sequence creation may be composed by security or other
extensibility as CreateSequence element allows today.
Disallowing [Detail] to contain any element, we are restricting extensibility
and ways for tools to interpret the reasons for create sequence to fail. We
think that the [Detail] element content may be used for including additional
information which may be specific to a platform, composition or extension. Target:
core Proposal:
Allow [Detail] to contain any content, instead of requiring it to be empty. [1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf
Agreed to accept proposed 02 as a new issue. – owner Umit 4.3
Proposed-03
Title:
Reword "Closing a Sequence" section Description: Section 3.6
"Closing a Sequence" contains in introduction to the close operation,
and its justification. I think that the current text would benefit from a
rework. Lines 625 - 648 of working draft 05 say: There may
be times during the use of an RM Sequence that the RM Source or RM Destination
will wish to discontinue using a Sequence even if some of the messages have not
been successfully delivered to the RM Destination. In the case
where the RM Source wishes to discontinue use of a sequence, while it can send
a TerminateSequence to the RM Destination, since this
is a one-way message and due to the possibility of late arriving (or lost)
messages and Acknowledgements, this would leave the RM Source unsure of the
final ranges of messages that were successfully delivered to the RM
Destination. To
alleviate this, the RM Source can send a <wsrm:CloseSequence>
element, in the body of a message, to the RM Destination to indicate that RM
Destination MUST NOT receive any new messages for the specified sequence, other
than those already received at the time the <wsrm:CloseSequence>
element is interpreted by the RMD. Upon
receipt of this message the RM Destination MUST send aSequenceAcknowledgement
to the RM Source. Note, this SequenceAcknowledgement
MUST include the <wsrm:Final>
element. While the
RM Destination MUST NOT receive any new messages for
the specified sequence it MUST still process RM protocol messages. For example,
it MUST respond to AckRequested, TerminateSequence
as well as CloseSequence messages. Note, subsequent CloseSequence
messages have no effect on the state of the sequence. In the case
where the RM Destination wishes to discontinue use of a sequence it may 'close'
the sequence itself. Please see wsrm:Final
above and the SequenceClosed fault below. Note, the SequenceClosed Fault SHOULD be used in place of the SequenceTerminated Fault, whenever possible, to allow the
RM Source to still receive Acknowledgements. Justification:
The above text could be clearer. Target: core Type:
editorial Proposal: Replace the
above text (lines 625 - 648) with the following: There may
be times during the use of an RM Sequence that the RM Source or RM Destination
will wish to discontinue using a Sequence. Simply terminating the Sequence
discards the state managed by the RM Destination, leaving the RM Source unaware
of the final ranges of messages that were successfully delivered to the RM
Destination. To ensure that the Sequence ends with a known final state both the
RM Source and RM Destination may choose to 'close' the Sequence before
terminating it. If the RM
Source wishes to close the Sequence then it sends a <wsrm:CloseSequence> element, in the body of a message,
to the RM Destination. This message indicates that the RM Destination MUST NOT
receive any new messages for the specified sequence, other than those already
received at the time the <wsrm:CloseSequence>
element is interpreted by the RMD. Upon receipt of this message the RM
Destination MUST send a SequenceAcknowledgement to
the RM Source. Note, this SequenceAcknowledgement
MUST include the <wsrm:Final>
element. While the
RM Destination MUST NOT receive any new messages for
the specified sequence it MUST still process RM protocol messages. For example,
it MUST respond to AckRequested, TerminateSequence
as well as CloseSequence messages. Note, subsequent CloseSequence
messages have no effect on the state of the sequence. In the case
where the RM Destination wishes to discontinue use of a sequence it may close
the sequence itself. Please see wsrm:Final
above and the SequenceClosed fault below. Note, the SequenceClosed Fault SHOULD be used in place of the SequenceTerminated Fault, whenever possible, to allow the
RM Source to still receive Acknowledgements. Related
issues: None Doug B: when proposing scattered changes, can a pdf for change bars be seen, to bring out the changes in the emails. Paul F: that should happen before we close the issue. Agreed to accept Proposed 03 as new issue – owner Matt Lovett Abbie I send an proposal on state transitions. But the Kavi URL does not work. Marc G: the Kavi URL does not
exist. Need to use the new permanent URL 4.4
Proposed-04
Title:Remove LastMessage
Description:
The LastMessage element, as part of a Sequence header element,
appears superfluous. It seems to serve 2 purposes: 1 - force a SeqAck to be sent back
from the RMD 2 - force the RMD to reject any messages with a higher message #
#1 can be done
with an AckReq header. We should avoid having
multiple ways to do the same thing. #2 is
really only an issue if someone tries to hijack the sequence - and to protect
against that we should be using a real security mechanism like WS-SC/Trust, not
the LastMessage element. When an RMS
is done with a sequence it is free to simply Close or Terminate it (whether or
not it has all of the Acks it wants - but normally it
will wait) - having an additional message exchange to send a LastMessage is unnecessary. Justification:
See above. Target:
core Proposal:
Remove all references to LastMessage (and
related Fault) from the spec [1]. See
attached diff/pdf file for the specific changes. [1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf Origin: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00019.html Agreed to accept proposed 04 as a new issue – owner Doug D 4.5
Proposed-05
Title:
Replace 'response' Description:
under figure 2, for step 7 replace:
7.The RM Destination acknowledges
receipt of message numbers 1 and 3 in response to the RM Source's <wsrm:LastMessage> token. with
7.The RM Destination acknowledges receipt of message
numbers 1 and 3 as a result of receiving the RM Source's <wsrm:LastMessage> token. Justification:
"response" could be misleading since some may think of it as a
request/response thing. Basically just a minor editoral change. We need easy ones for our
conf calls :-) Target:
core Proposal:
see above. [1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf Agreed to accept Propose 05 as a new issue
– owner Doug D. 4.6
Proposed-06
Title:
Remove 'correlation' text Description:
In section
2.2 the spec [1] says: The RM
Source MUST have an endpoint reference that uniquely
identifies the RM Destination endpoint; correlations across messages addressed
to the unique endpoint MUST be meaningful.
Does anyone know what correlations its
talking about? If not this text seems pretty useless and should be moved
as it could be misleading for some people to think we're talking about
WS-Addressing correlation or something. Justification:
Leads to confusion. Target:
core Proposal:
Remove the text after the semi-colon. [1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf Agreed to accept proposed 06 as new issue – owner Doug D: 5 Issue Discussion:Note new stable URL:
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml (Thanks to Paul Cotton for proposal analysis) ------------------------- 5.1 i022 Vikas Deolaliker RM Policy Assertion Model's Base
Retransmission Interval Clarification Needed http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i022 Aug 8 proposal: http://lists.oasis-open.org/archives/ws-rx/200508/msg00033.html
Sep 22 counter proposal: http://lists.oasis-open.org/archives/ws-rx/200509/msg00254.html
Nov 2 counter proposal: http://lists.oasis-open.org/archives/ws-rx/200511/msg00021.html Bob F posted newer proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00207.html Vikas gave an overview of the state of the issue discussion. Bob’s latest mail has a proposal Bob: proposal: Argument: Retransmission parameters as well
as algorithms are problematic for the following reasons: 1) The characteristics of the path from
source to destination are often unknown and often are time-variant. 2) Retransmissions if too frequent cause
flooding and potential catastrophic degradation if the path is near saturation 3) The path may consist of not only
transmission means, but also intermediaries with attendant processing delays 4) Exponential back off may be implemented
many ways, there is more than one algorithm that use different parameters 5) Back off algorithm selection may be
implementation specific, what is good for cell phones may not be good for
cluster interconnected nodes or crossbar connected multiprocessors 6) I have found no theoretical modeling
published concerning stability of specific back off algorithms which consider
the case of web services cum intermediaries 7) Most published data concerning the
behavior of back off algorithms examine fairly simple network segment related
saturation and do not address client, server, let alone intermediary
saturation. 8) Exponential back off algorithms need an
adaptive recovery mechanism for those situations where there is a high standard
deviation of delay. 9) TCP/IP experience has shown that
efficiencies are improved with an adaptive mechanism as described in TCP
Extensions for High Performance (see RFC 1323 RTTM) Proposal: Clearly a back off mechanism is
required; however implementation specific needs are not served well by the
specification of any specific algorithm for all potential implementations of
WS-RM. It is recommended that
implementers utilizing IP based transmission media consider the mechanism described
in RFC 1323. In additions, acceptance of
this proposal removes all mention of re-transmission which is a required for
correct operation of the protocol. These however are beyond the scope of the
issue as stated. Therefore: Delete all re-transmission
parameters as described in the WS-RM Policy specification [1] since they are
unnecessary and unhelpful should the implementer use an algorithm with a
different set of controls. Note: A new issue should be opened to
address the location and manner by which re-transmission behavior is specified. Document with changes: wsrmp-1.1-spec-wd-01-i022markup.pdf Bob: Inactivity timeout was the only parameter to retain Umit: we prefer to also retain Ack Interval Anish: Can Bob explain why Inactivity timeout should not be there, while ack interval should not. Bob F: I did not strike inactivity timeout, because it is only for cleanout of state. However, I see not real need for it, but would not complain too much as long as it remains optional. We did not find a fundamental reason for ack interval as a parameter. Piggyback is one activity which could benefit (on a heavy channel you may want to reduce bytes in a direction, with tradeoff on latency). The difficulty of specifying an ack interval is that it adds latency. Doug B: It is not true to paraphrase that we are in agreement to keep ack interval. Anish: all these four parameters depend on who you are talking to, and should not be static declared in policy.. However there have been interesting discussions on timeout. Bob F: it is not required to specify the relationship of ack interval and inactivy timout in the specification, an implementation can deal with this. Umit: where will RMS determine rate at which acks will be received? What is purpose of policy doc? If it is to specify what rmd can do, ack interval is useful to be expressed, because it can be consumed by RMS. Giovani: Ack interval is a hint for buffer and flow control heuristics. It is useful for RMS to have, even if it is not binding. I think it is a useful parameter. Vikas: if it important is should be in the protocol. Sanjay: having ack interval can help RMS. The reason in the spec is that ack interval is use for piggybacking. The rationale in the spec does Tom R: I do not agree with Vikas, it should not be in the protocol unless it is necessary. The protocol will work without knowledge of these parameters. Anish: the parameters are not described well. Are they static, or just initial values. Can anyone shed light on their use. Doug D: I move resolve Issue 022 we drop base retransmission and exponential backoff. That is to accept Chris F proposal. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00060.html Seconded by Stefan. Bob F: I had put out a proposal a couple of weeks ago to add text for clarifying retransmission. Marc G: that is Issue 059. Giovanni: I am concerned about this new issue. I do not see that this in the protocol is in the issue. Sanjay: if the retransmission requires protocol change, we can do it as part of the resolution. Giovanni: the ambiguity of the new issue is of concern, but I am ok with it. Bob F: I will post a modest proposal for resolution, My intent is to just specify that a retransmission mechanism is required. Umit: what is difference between Chris F proposal and mine. Paul F: is anyone opposed to the motion. Vikas: I do not want to resolve this until Issue 059 is resolved. We have work to do. Sanjay: Issue 59 is still open, Would you vote against this motion. Vikas: probably not. I feel the full resolution requires resolution of 59 as well. § No objection to motion,: issue 022 is resolved by removing base retransmission interval and exponential backoff. 5.2 i023 Marc Goodner Robust
recovery from low-resource conditions http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i023
Proposal from original issue: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00252.html
Oct 12 counter proposal: http://lists.oasis-open.org/archives/ws-rx/200510/msg00062.html
Marc G: the original proposal from Chris F was to close issue i023 with no change. Flow control is beyond the scope of ws-rm. Nov 2nd proposals: http://lists.oasis-open.org/archives/ws-rx/200511/msg00041.html Steve W discussed their proposal, to include a retryAfter element in the response. Tom R: there are some capabilities for flow control in TCP itself, if http pipelining is used, this can help. Doug D: such flow control is not RM specific, so it should be out of scope of this spec. Doug D: I move to close issue 023 by dropping with no change. Marc G seconded. Jacques: I would not like to see redundancy of flow control as part of the reliability spec. I am not in favor of pause/resume proposal. I can accept this proposal. Bob F: I speak in favor of the motion. Thinking on reliability associated with flow control., it is mis layered to put as part of ws-rm. Steve W: I speak against closing with no action, it is useful functionality. It is not necessarily overstepping our bounds. Doug D: would it not be better to attack in a general purpose manner. Steve W: since no other spec exists, I prefer to attack it here. Especially if it is sequence specific, it could be resolved as part of our spec. Umit: I agree with Steve, we are defining a protocol, and somebody has to do something at some point. Our proposal is within the context of ws-rm sequences. Doug B: How did we get from not liking flow control implication of proposal 2 of Steve, to closing this without action. What about proposal 1 of Steve’s Mail?, What is negative about giving a specific error for this case? Duane N; If something happens this needs to be considered more. If TCP does it there could be some interactions. WS-transmission control could resolve this issue. I do not see how we can do anything other than closing at this time. Steve: if RM layer does not have sufficient resources it is its own problem. The first proposal is simple, to add an error code. While we prefer the advanced proposal of flow control, the second one is better. Chris F: This is outside of the scope of the charter of this TC. Steve W: the charter states we can handle the efficient retransmission of messages. Tom R: As Duane stated, backpressure flow control on a tcp connection used for http pipliing will take place, with a busy rmd, before the rmd has a chance to issue this new flow control. Umit: this is not just for network problems. Motion to call question. § No objections to call question, motion passes. Vote: 29 yes, 2 no, 7 abstains § motion to close i023 with no change passes. 6 Any other businessMeeting closed at normal stop time, 5:30 PM Eastern Standard Time |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]