[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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? 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 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). b] Do store and forward "intermediaries" implement WS-RM over SOAP or are they strictly SOAP entities that are unaware of WS-RM? 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. 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? 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]