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: RE: [wsrm] Assumptions of the Transport Protocol Layer + COnfiguration Mgt


Paolo

While I appreciate your perspective and opinion below, I agree with others who believe that a formal binding definition/ finite state machine description should not be a high priority work item for WS-RM TC.  Hence, I continue to recommend and Appendix/Informative Annex for transport bindings with examples and notes.

It is my understanding that "implementations interoperability" is the prime objective of the WS-I organization and NOT this TC.

Any other opinions out there?

alan

 ----- Original Message -----
From: Paolo Romano <romanop@dis.uniroma1.it>
Date: Tue, 29 Apr 2003 15:40:31 +0200 (MEST)
To: Alan Weissberger <ajwdct@technologist.com>
Subject: RE: [wsrm] Assumptions of the Transport Protocol Layer +    COnfiguration Mgt

> 
> > Along with the original mail below, here are a few additional points:
> >
> > 1.  WS-RM spec should NOT specify how the WS-RM implementation can rely
> > on Transport layer's functionality to provide Guaranteed
> > Delivery/Duplicate Elimination/Ordering features.  WS-RM spec must
> > provide all those capabilities independent of Transport layer.
> >
> > 2. How to make use of the Transport layer's features for SOAP message
> > reliability is an implementation issue, not subject to standardization.
> > 3.  Providing bindings/Transport layer examples in an Appendix would
> > help people better understand the WS-RM specification, help them with
> > setting of configuration parameters, and understand what type of
> > anomalies may happen at which layer.  The aim of the Appendix would be
> > to show example higher layer protocol stacks, with appropriate notes,
> > which would validate the feasibility of WS-RM spec.
> >
> 
> I do not agree with your point of view. In my opinion it would be a key
> factor for the success of these specifications to provide a formal
> definition of the binding with the possible underlying transport
> protocols.
> 
> IMO an efficient way to do this is by defining a formal description
> through finite state machines. These would be a precious input for any
> developer team in order to ensure interoperability of final
> implementations. Moreover, even if defining finite state machines
>  rather than just showing some examples, may result in a harder work for
> this TC, our effort would result in a much clearer and unambigous
> specification. Also, one may prove formally the correctness of the
> estabilished mechanism, despite failures. Independently of the latter
> point, i'd like to outline that my focus is on implementations
> interoperability (JMS experience should make us think).
> 
> 
> 
> >  4.  While WS-RM configuration management is out of scope, the values of
> > NO ACK timer and retry counter will be dependent on Transport binding/
> > Transport protocol so as to avoid retransmissions at multiple layers
> >
> > ***Suggestion:  at some point (f2f meeting?) we should discuss how
> > configuration setting/ re-configuration is done even if such a
> > capability is not included in the initial WS-RM spec.  At some later
> > time we could define a Header field for a WS-RM (remote) CONFIGURATION
> > message or a CAPABILITY/PARAMETER EXCHANGE message.  The message body
> > would contain the various parameters/MEPs supported.
> >
> > Food for thought
> >
> > Thanks
> >
> > alan
> >
> >
> > ----- Original Message -----
> > From: "Alan Weissberger" <ajwdct@technologist.com>
> > Date: Mon, 28 Apr 2003 17:15:22 -0500
> > To: magdolna.gerendai@nokia.com,tom@coastin.com,Doug.Bunting@Sun.COM
> > Subject: RE: [wsrm] Assumptions of the Transport Protocol Layer + Intermediaries
> >
> > > Magdolna
> > >
> > > Thanks you for your comments below.  Here is our current thinking:
> > >
> > > I.  BIndings and Tranport layer protocol
> > >
> > > Question for clarification:  In your remarks below you say "filtering of corrupted messages."  Does that mean binding  will identify and discard them?
> > > ---------------------------------------------------------------------
> > > Our thoughts:  While WS-RM spec should work independent of bindings and Transport layer protocol, we still recommend that examples of transport bindings be contained in an Appendix/ Informative Annex of the spec.
> > >
> > > This is because the choice of binding (and how the binding uses TCP or a
> > > different Transport protocol) will determine the  reliability and
> > > robustness of the end to end messaging connection.  The Transport layer protocol (and how it is used) may also be important for the configuration setting of WS-RM parameters (e.g. No ACK timer and retry counter) and meaning/ interpretation of WS-RM failure indications.
> > >
> > > With that said up front, here are our thoughts on WS-RM relationship
> > > to transport bindings:
> > >
> > > 1.  WS-RM should provide end to end reliable delivery of SOAP
> > > messages/MEPs to the App layer above, independent of the transport
> > > binding below.  See point 4. below
> > >
> > > 2.  Each type of SOAP MEP requires a separate binding, e.g. 1-way,
> > > Request/Response, other?  Any binding that supports SOAP MEPs can be
> > > used.  However..................
> > >
> > > 3.  The choice of binding (and associated Transport layer protocol) will dictate the reliability and robustness of the underlying end to end connection.  SOAP messages may be lost, duplicated, or arrive out of sequence, depending on the inherent reliability of the underlying subnetworks, the transport binding, and how that binding invokes TCP or another Transport layer protocol (?).
> > >
> > > For example there are (atleast) two stated uses of TCP by HTTP toolkits:
> > >
> > > a]  A separate TCP connection is set up for each HTTP message
> > > b]  One TCP connection is set up for all HTTP messages
> > >
> > > Note that a] will be less reliabile, with SOAP message misordering more likely due to different end to end paths and associated transit delays.
> > > In a network overload situation, TCP flow control is possible with b], but not with a].
> > >
> > > 4.  WS-RM layer will attempt to recover from message loss,
> > > duplication, or misordering, independent of the binding, Transport
> > > layer protocol and how it is invoked.
> > > ---------------------------------------------------------------------
> > >
> > > B.  Intermediaries
> > >
> > > If WS-RM aware intermediaries are to be present, we need to carefully specify what WS-RM functionality (or subset of the spec) they implement.
> > > Regarding correlation of mesgs and ACKs via global unique Identifiers:
> > >
> > > are you saying/implying below that an intermediary will change the Message ID Element (3.1.4 in the WS-RM 1.0 spec)as part of the store and forward process?  If not, then how does the sender know if an ACK is being sent by the intermediary or end point WS-RM entity?  In my opinion, you need the equivalent of the X.25 PLP Delivery Confirmation bit to determine if the ACK is local or end to end significance.
> > >
> > > Thanks for your attention
> > >
> > > alan
> > >
> > >
> > > ----- Original Message -----
> > > From: <magdolna.gerendai@nokia.com>
> > > Date: Fri, 25 Apr 2003 15:43:16 +0200
> > > To: <ajwdct@technologist.com>, <tom@coastin.com>, <Doug.Bunting@Sun.COM>
> > > Subject: RE: [wsrm] Assumptions of the Transport Protocol Layer +    Intermediaries
> > >
> > > > Hi all,
> > > >
> > > > See my comments below.
> > > >
> > > > br,
> > > > Magdolna
> > > >
> > > > -----Original Message-----
> > > > From: ext Alan Weissberger [mailto:ajwdct@technologist.com]
> > > > Sent: April 21,2003 19:22
> > > > To: tom@coastin.com; Doug.Bunting@Sun.COM
> > > > Cc: wsrm@lists.oasis-open.org
> > > > Subject: Re: [wsrm] Assumptions of the Transport Protocol Layer +
> > > > Intermediaries
> > > >
> > > >
> > > > Tom, Doug, and others,
> > > >
> > > > Sorry for the late comment, but I was in Japan last week with no access to email
> > > >
> > > > Here are my thoughts on this issue + comment on Intermediaries:
> > > >
> > > > 1.  We should provide examples of WS-RM/SOAP bindings in Appendix to the WS-RM spec.  Each binding should state the assumed Transport protocol.  I believe that both HTTP and SMTP assume TCP for Transport protocol.  Is there any binding that uses UDP or other Transport protocol, e.g.  ISO TP class 0-4?
> > > >
> > > > [MG] The Transport protocol terminology is misleading here, because it usually means ISO/OSI transport layer protocols (TCP,UDP, etc..), but our intention is to use the current standard SOAP bindings, i.e. HTTP, maybe SMTP. For being transport binding independent on Reliability level, we just should define the minimal requirement against any kind of (current and future) underlying (transports) bindings on the following way: any SOAP bindings must ensure the filtering of the corrupted messages.
> > > >
> > > >
> > > > 2. Flow Control
> > > >
> > > > While TCP provides end to end transport flow and congestion control, there may be a need for Application layer- to - WS-RM layer flow control, depending on how message buffer queues are handled.
> > > >
> > > > However, I believe that the all aspects of Application layer- to - WS-RM layer communications should be specified in a separate "API for WS-RM" specification
> > > >
> > > > [MG] I'm afraid, the flow-control leads too far from the original aim. I do agree with the definition of abstract primitives describing the Application - Reliability layer communication, as we discussed during the last telcon.
> > > >
> > > >
> > > > 3. Intermediaries???
> > > >
> > > > a]  If intermediaries are present than we must deal with concatenated Transport connections (each connection is "end to end" as far as Tranport layer is concerned).  If one of the intermediate connections times out (w/o an ACK) or fails, then TCP will try to recover by  re-transmitting the TPDU (=Tranport layer packet).  Hence, WS-RM should be tolerant of intermediate Transport connection anomalies/ failures by setting it's NO ACK Timer value to be >> than any corresponding TCP timer value (a somewhat weaker case can be made w/o any intermediaries).
> > > >
> > > > [MG] This is generally true for any kind of intermediaries, and not specific for the SOAP intermediaries. This means only, that if concatenated connections can be assumed, the Retry timer should be set carefully. The WS-Reliability proposal doesn't tell anything about the preconditions of the reliability settings (pre-configured, how to define, configuration management(?), etc..) So we should do it as well.
> > > >
> > > >
> > > > b]  Do store and forward "intermediaries" implement WS-RM over SOAP or are they strictly SOAP entities that are unaware of WS-RM?
> > > >
> > > > [MG] Yes and no. From reliability point of view we should define the following: a SOAP intermediary may implement WS-reliability. It's a configuration issue, and may be necessary, if the intermediary,  does non-idempotent processing on the incoming SOAP messages (e.g. duplicate elimination needed).
> > > > The requirement:  the Specification defines processing rules and (pre-)conditions for reliable SOAP intermediaries, which are involved in  distributed processing of non-idempotent messages.
> > > >
> > > >
> > > > If they implement WS-RM, then there are a whole new set of WS-RM issues (e.g. local vs end to end significance of ACKs and fault indications; end to end sequence preservation/ message ordering, etc) which must be resolved.
> > > >
> > > > [MG] The correlation of the messages and their Acks are based on global unique identifiers, so no need to differentiate them as local, or end-to-end. Moreover there is no need to keep any sequenced message order, if otherwise the communication doesn't require it, they behave from this point of view as "usual" network intermediaries.
> > > >
> > > >
> > > > 4. HTTP (and other) toolkits "hiding TCP level detail," specifically TCP encountering a transport connection failure due to broken link or failed intermediate node, e.g. a router.
> > > >
> > > > Is there a "Transport failure" primitive/ parameters passed up the protocol stack to the HTTP/SMTP entity?
> > > > Are SOAP messages  queued (or dropped) by HTTP/SMTP until the Transport connection is re-established?
> > > >
> > > > Issue:  If there is no notification of Transport connection failure, all "transmitted" WS-RM/SOAP  messages will be sent down to HTTP/SMTP, where they might me queued, but not actually transmitted.
> > > >
> > > > Shall we assume that this is strictly a HTTP/SMTP toolkit issue, or do we need to consider it in the WS-RM work?
> > > >
> > > > [MG} I think, we do consider the issues above only from that point of view, what is their implication for the Reliability layer. It just means, that messages may be lost, or duplicated.
> > > >
> > > > 5.  Value of WS-RM No Ack Timer [Yes, I know this is "configuration management"]
> > > >
> > > > We should state that WS-RM NO ACk timer value should be >> TCP NO ACk timer value.    If not, then a lost TPDU will result in re-transmissions at both WS-RM and Transport layers.  This would cause excessive WS-RM/SOAP message duplication.
> > > > -------------------------------------------------------
> > > >
> > > > Perhaps we can separately discuss Transport layer dependency and Intermediaries in this Tuesday's conf call
> > > >
> > > > alan Weissberger
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: Tom Rutt <tom@coastin.com>
> > > > Date: Fri, 11 Apr 2003 19:41:08 -0400
> > > > To: Doug Bunting <Doug.Bunting@Sun.COM>
> > > > Subject: Re: [wsrm] Assumptions of the Transport Protocol Layer
> > > >
> > > > > Doug,
> > > > > I agree with your clarifications. I was making broad brush statements
> > > > > which you have appropriately qualified.
> > > > >
> > > > > Is all we are relying on is message integrity preservation in the
> > > > > transport layer?
> > > > >
> > > > >
> > > > > It seems that flow control would be another thing to rely on the
> > > > > transport protocol for.
> > > > >
> > > > > Anyway, we need to get our requirements sorted out in this area.
> > > > >
> > > > > Tom Rutt
> > > > > Fujitsu
> > > > > Doug Bunting wrote:
> > > > > > Tom,
> > > > > >
> > > > > > I slightly disagree in a few of the details you provided.  Please see
> > > > > > below, most of which is additional food for thought.
> > > > > >
> > > > > > On 11-04-2003 13:13, Tom Rutt wrote:
> > > > > >
> > > > > >> At the last WSRM TC meeting we initiated discussion on the assumptions
> > > > > >> the requirements should make on the Transport Protocol capabilities.
> > > > > >>
> > > > > >> It was stated that the Co-sponsors assumed TCP under HTTP.
> > > > > >
> > > > > > I think it was stated that we assumed a protocol at least that good, not
> > > > > > necessarily exactly that configuration.
> > > > > >
> > > > > >> There were some statements that TCP connections give flow control, and
> > > > > >> sequencing capabilties already.
> > > > > >>
> > > > > >> However, we need to address reliability at the app to app level.
> > > > > >
> > > > > > Or, in a message and not packet granularity.
> > > > > >
> > > > > >> Even if the http layer implements use of Persistent TCP connections,
> > > > > >> the sending app does not know if the receiving app received the
> > > > > >> message successfuly, when the TCP layer signals a connection failure.
> > > > > >
> > > > > > In some cases, this is a toolkit problem.  Most HTTP toolkits hide TCP
> > > > > > level detail, such as where in the outbound or inbound stream the system
> > > > > > encountered an error, from the application.  The other part of this
> > > > > > issue comes back to the intermediates expected in future SOAP
> > > > > > deployments.  TCP reliability gets packets from one point to another but
> > > > > > does not help with end to end assurances except as it reduces the
> > > > > > frequency of problems.
> > > > > >
> > > > > >> Another concern is that the WS-RM sender may use more than one TCP
> > > > > >> connection for its  outgoing message sequences.   Thus, when sequences
> > > > > >> of sent messages span multiple transport connections, the messages can
> > > > > >> arrive out of sequence, or succeeding on one message while failing on
> > > > > >> a subsequent message.
> > > > > >
> > > > > > Issues with ordering dependencies also arise with unpredictable
> > > > > > store-and-forward intermediaries.  On the other hand, we need a clear
> > > > > > use case for handling multiple outstanding (unacknowledged) requests in
> > > > > > parallel.  This use case doesn't exist in the WS-Reliability starting
> > > > > > point though we did do technical work on a solution.
> > > > > >
> > > > > > thanx,
> > > > > >     doug
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > ----------------------------------------------------
> > > > > Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
> > > > > Tel: +1 732 801 5744          Fax: +1 732 774 5133
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > Alan Weissberger
> > > > 2013 Acacia Ct
> > > > Santa Clara, CA 95050-3482
> > > > 1 408 863 6042 voice
> > > > 1 408 863 6099 fax
> > > >
> > >
> > >
> > >
> > > Alan Weissberger
> > > 2013 Acacia Ct
> > > Santa Clara, CA 95050-3482
> > > 1 408 863 6042 voice
> > > 1 408 863 6099 fax
> > >
> >
> >
> >
> > Alan Weissberger
> > 2013 Acacia Ct
> > Santa Clara, CA 95050-3482
> > 1 408 863 6042 voice
> > 1 408 863 6099 fax
> >
> >
> 



Alan Weissberger
2013 Acacia Ct
Santa Clara, CA 95050-3482
1 408 863 6042 voice
1 408 863 6099 fax



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