RE: RM and Intermediaries

> -----Original Message-----
> From: Ricky Ho [mailto:riho@cisco.com]
> Sent: Sunday, January 26, 2003 9:12 AM
> To: Assaf Arkin; www-ws-arch@w3.org
> Subject: 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 ?

We need to distinguish between two types of intermediatries. Stateless
intermediaries who just forward the message. If X is a stateless
intermediary then X does not ack, B and possibly Y before B would. You can
decide to send through X and resend through Z.

Stateful intermediaries (in effect queues) both forward and ack
(node-to-node ack, not end-to-end ack). If they give you the same level of
reliability (e.g. by persisting) then you don't need to resend (since they
will eventually deliver = send to the next node). But you can resend and
again you can send through X and resend through Z.

Whichever way you get the ack form B does not matter, but B will have to
eliminate duplicate messages. That is why in RM you send a message only once
but you may receive multiple times. Because from sending to receiving you
can use multiple paths alternatively, but even in parallel (sending through
X and Z at the same time is acceptable).

You can get level 4 reliability between A and B even if A-X only does level
1, X-Y only does level 0 and Y->B have no RM whatsoever.


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

Yes. The specification talks about A->B (end-to-end) so whatever happens
inbetween needs to conform to that, and the only way it can conform is if
you can elect to use different paths. And because duplicate messages are
eliminated you can use multiple paths at the same time.


> 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 ?

If the same message is sent twice through the same intermediary the
intermediary may choose to eliminate the duplicate, or forward the
duplicate, and may by itself introduce duplicates (by resending).

If idempotent means the intermediary forwards the same message only once
then no, the intermediary does not have to be idempotent. It may forward the
message as many times as it wants on its own accord.

If idempotent means the intermediary forwards the message as if it has never
seen if before then no, the intermediary does not have to be idempotent. The
intermediary may detect duplications and forward a message only once (e.g.
if it received an ack at the same time as it was asked to retransmit).


> 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 ?

It is the responsibility of the end node to deliver at-most-once, so you
don't need a coordination protocol to make sure the message is forwarded
only once. Though, you may want an RM or coordination protocol to determine
if the intermediary will attempt to forward the message.

For example, X and Y could be queues and they could use transactional
protocols to get message from A to X, X to Y, and Y to B, but in different
transactions, hence allowing for time independence of send and deliver.

arkin


>
> 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 17:13:01 UTC