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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[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 Rutt

Title: Preliminary Minutes WSRX TC Teleconf

Preliminary Minutes  WSRX TC Teleconf

 Nov 03, 2005 –

 

 

Tom Rutt agreed to take the minutes.

1         Roll Call

From Kavi,

 

 

Meeting is  Quorate

2         Review and approve of Agenda

1) 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 minutes

http://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 Issues

2.1      Status of CD posting and stable URLs

Gil: 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 F2F

A 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 Review

http://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 call

http://lists.oasis-open.org/archives/ws-rx/200511/msg00057.html

 

 

4.1      Proposed-01

Title: 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 business

 

Meeting 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]