RE: [wsrm] NEC Position on WS-RM flow/congestion control due tonetwork overload

[Paolo Romano <romanop@dis.uniroma1.it>]

I agree with Alan's CONCLUSION as well.

Paolo


> Hi Alan,
>
> I agree with the CONCLUSION.
>
> br,
> Magdolna
>
> -----Original Message-----
> From: ext Alan Weissberger [mailto:ajwdct@technologist.com]
> Sent: April 29,2003 21:12
> To: wsrm@lists.oasis-open.org
> Subject: [wsrm] NEC Position on WS-RM flow/congestion control due to
> network overload
>
>
> All
>
> Note:  This issue has nothing to do with App layer to WS-RM layer w/n one end system.  That is a local issue and needs to be addressed in the so called "WS-RM Services Layer interface to Apps layer," if we decide to pursue it.
>
> Instead, we are considering network congestion here.
>
> 1. Background:  In our last telecon, we agreed that the SOAP- HTTP binding needed to be supported and that HTTP always relied on TCP below as Transport layer protocol.  However, there are evidently two uses of TCP by HTTP toolkits:
>
> a)  A separate TCP connection is set up for EACH HTTP message exchange.  THis implies that SOAP messages will likely arrive out of sequence due to different end to end paths with correspondingly different end to end transit delays.
>
> --->This also impllies that TCP flow control can't be used since the TCP connection is taken down after a single HTTP message is transmitted
>
> b)  One TCP connection is set up for all HTTP messages sent(this is less likely to be implemented). This type of HTTP-TCP relationship would provide better sequencing/ordering as well as TCP based flow control. Unfortunately, Tom Rutt says few HTTP toolkits pursue this way of invoking TCP.
>
>
> 2.  Is there a need for WS-RM flow/congestion control???:
>
> In case 1. a) above, a network could become congested, but there would be no effective TCP flow/congestion control mechanism available to deal with it.  At first thought, it seems that some form of WS-RM congestion/flow control would be required to throttle back the transmitter during such an "overload condition."
>
> On further examination, however, WS-RM flow control would NOT be practicable.  The reason is that there is no Congestion Indication/ Congestion Experienced passed to the WS-RM layer from a layer below.
>
> --->Hence, there is no way for WS-RM layer to distinguish between a (repeat) failed connection and a network overload situation.
>
> Consider that some HTTP toolkits "hide TCP level detail," including transport connection failure.  Specifically, if TCP encounters a transport connection failure (due to broken link or failed intermediate node or link), there is unlikely to be a "Transport layer failure" primitive/ parameters passed up the protocol stack from TCP to HTTP to the WS-RM entity.  As a result, WS-RM/SOAP messages  will be passed down the protocol stack, but either dropped or queued by HTTP entity until the Transport connection is re-established.
>
> This will result in message loss, until a good transport connection is re-established.  The WS-RM receiving entity would not even know that messages were being lost (except for ACKs or Responses that were expected).  It would not be able to distinguish this condition from a network overload situation.
>
> 3.  Conclusion:  As WS-RM entities can NOT DISTINGUISH BETWEEN TRANSPORT
> CONNECTION FAILURE(s) and NETWORK OVERLOAD CONDITION(s), it is NOT
> practicable to consider WS-RM FLOW/CONGESTION CONTROL.
>
> -->ONLY IF A CONGESTION INDICATION/CONGESTION EXPERIENCED INDICATOR IS
> AVAILABLE (set by a lower layer and passed up the protocol stack to
> WS-RM entity) SHOULD WE EVEN CONSIDER THIS FUNCTION IN WS-RM.
>
> Thank you for your attention
>
> alan
>
>
>
>
>
> Alan Weissberger
> DCT
> 2013 Acacia Ct
> Santa Clara, CA 95050-3482
> 1 408 863 6042 voice
> 1 408 863 6099 fax
>
>