RE: RM and Intermediaries

Regarding the difficulty in setting "retry-timeout" value not only exist 
when multi-protocol segments are involved.  Even when all intermediaries 
are talking the same transport protocol, there is an intermediary 
processing step involve, how long it takes is always unpredictable.

Lets go back to (A->X->Y->B) ...

1) Are the intermediary processing (e.g. at X and Y) required to be 
idempotent ?  (I haven't seen duplication elimination at the intermediary 
level being mentioned in Assaf and David's mail).  Does the point-to-point 
ACK have the same "5-level" of RM sophistication as David describe earlier ?

2) If A doesn't get an end-to-end ACK from B.  In its retry, can A pick a 
different path (A->M->N->B) when resend ?  (Point-to-point ACK/NACK helps A 
here to provide information about fail nodes so that A can quickly choose 
how to bypass the failure node, again another performance optimization)

3) If a different path in RM is allowed, then just intermediary level 
duplicate detection cannot provide "at-most-once" semantics for the 
intermediary processing.  Does this mean the intermediary processing has to 
be idempotent ?

4) If the intermediary processing is NOT idempotent, does it mean a 
co-ordination protocol is required to guarantee the atomicity of 
intermediary processing and end-point processing ?

Best regards,
Ricky

At 05:06 PM 1/25/2003 -0800, Assaf Arkin wrote:

>How about message encapsulation?
>
>If service A sends a message to service B through intermediaries X and Y
>(A->X->Y->B), then service A is only interested in getting an ack from
>service B (end-to-end).
>
>However, the RM at A may be interested in getting an ack from X, and the RM
>at X may be interested in getting an ack from Y. In that way if A
>successfully delivers to X, then A gets one ack from X, does not attempt to
>resend and waits for ack from B.
>
>If X successfully delivers to Y then X gets an ack from Y but never waits
>for anything else. (For X, the ack coming back from B is a different message
>that needs to be acknowledged in its own right).
>
>If Y successfully delivers to B then Y gets an ack for that delivery, which
>means it can stop resending to B. The ack the B sends to A is a different
>message (as far as Y is concerned), and may go directly to A or travel back
>through Y->X with acks going back from A->X->Y->B to confirm delivery of
>ack.
>
>Whether A->X->Y->B do that is dependent on the protocol they use. Whether
>A->B do acks is dependent on the use of a WS RM.
>
>A may talk to X using HTTP and not require any protocol-level ack. X may
>talk to Y using UDP and may require protocol-level ack. X may talk to Y
>using some MOM and have absolutely no clue whether the MOM does or does not
>use ack. Some implementations have different ways of doing acks without
>sending ack messages at all (e.g. a reliable multicast may send nacks and
>piggyback acks into data packets).
>
>However, at its discretion X may decide to wrap the message sent by A into a
>larger message and then use WS RM to send that message to Y getting a WS RM
>ack from Y for the message sent by X, indicating successful delivery from X
>to Y (in effect encapsulating one message inside another). Y then extracts
>the underlying message, wraps it again and delivers to B.
>
>I think that is consistent with what David has been saying, it just proposes
>multiple strategies for protocol-level acks that do not change the semantics
>of the WS ack. It also highlights that using the reverse path is optional.
>
>You could have a path A->X->Y->B and reverse path for the ack B->Z->A.
>However, if X gives you some feature you want to retain for all messages
>(e.g. validating the certificate) you would want to include X in the reverse
>path. In that case you will need some header to indicate which nodes should
>be part of the reverse path (e.g. WS-Routing).
>
>arkin
>
>
> > -----Original Message-----
> > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> > Behalf Of Ugo Corda
> > Sent: Saturday, January 25, 2003 4:50 PM
> > To: Ricky Ho; www-ws-arch@w3.org
> > Subject: RE: RM and Intermediaries
> >
> >
> >
> > Last month I raised a similar issue, and I got an extensive
> > response from David Burdett at [1], which you might want to look at.
> >
> > Ugo
> >
> > [1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0095.html
> >
> > > -----Original Message-----
> > > From: Ricky Ho [mailto:riho@cisco.com]
> > > Sent: Saturday, January 25, 2003 7:50 AM
> > > To: www-ws-arch@w3.org
> > > Subject: RM and Intermediaries
> > >
> > >
> > >
> > > Lets say S is the sender endpoint, R is the receiver
> > > endpoint, and i1, i2
> > > are intermediaries that pre-process the message.
> > >
> > > S --> i1 --> i2 --> R
> > >
> > > Do i1 and i2 have to understand RM ? or RM is just an end-to-end
> > > handshaking between S and R ?  If so, can S pick a different
> > > path in its
> > > message resend ?
> > >
> > > Rgds, Ricky
> > >
> > >

Received on Sunday, 26 January 2003 12:13:06 UTC