RE: [ws-rx] PR001 - Feedback on MSFT's MC proposal

[Doug Davis <dug@us.ibm.com>]

Marc,
  comments inline.
 Overall, I think you need to show a lot of concrete sample message
flows to prove that your proposal is not only better than what's in the
spec but can even work at all because most of your answers don't address
the issues I've mentioned.

Another issue was realized the other
day, so I might as well mention it here:

Sequence Faults are sent to the AcksTo
EPR - this means that faults for the client->server sequence are sent
to the AcksTo EPR - which may be anonymous.
Normally when we talk about MC being
used we talk about it polling for messages related to the Offered Sequence
not the outbound/client->server sequence.  However, in order
for these client->server Sequence Faults to be delivered the client
MUST periodically poll for them.   So in this proposal how do the
Sequence Faults get returned?  This proposal is based on the MC being
sent to the AcksTo EPR but the AcksTo EPR is on the wrong side of the connection
for this sequence.  This proposal doesn't address how these Fault
messages can be delivered. 
The current spec doesn't have this issue
because the AcksTo EPR can use the same RManonURI as the other EPRs - which
means a single MC can be used to pull back any message that needs to be
sent - whether its an RM-enabled response or a SeqFault for the outbound
sequence. 

-Doug

Marc Goodner <mgoodner@microsoft.com>

11/01/2006 02:28 PM

To	Doug Davis/Raleigh/IBM@IBMUS, "ws-rx@lists.oasis-open.org" <ws-rx@lists.oasis-open.org>
cc
Subject	RE: [ws-rx] PR001 - Feedback on MSFT's MC proposal

Doug, 
 
Thanks for the feedback.
Detailed responses inline below. 
 
The net is I don’t see
anything below that can’t already be done using the proposal I made. As
I already mentioned in the response to Anish’s message the only potential
change to the proposal I made is adding a new EPR specifically for MC.
 
 
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, October 26, 2006 8:57 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] PR001 - Feedback on MSFT's MC proposal
 

Per my todo, here's feedback on the MSFT proposal for PR001 which
also has the various use-cases interspersed.

MG: My understanding is
that the AI you took was to provide a set of enumerated use cases so the
two proposals could be compared. I do not believe that this mail does that.
However, I’m willing to see the AI closed if you agree that you don’t
have any additional use cases beyond this for MC.

Metacomments: 
- Current solution in spec is not broken nor incompatible with WSA

 
MG: If this were true
CR33 would not have been filed.
DUG: No matter how
CR33 ends up (even close w/no action) the current RM spec can compose with
WSA - the only thing that needs to be made clear is the value people should
use for wsaw:Anonymous. No biggie.  CR33 wasn't opened because RM
couldn't work today but rather because of a problem with WSA.

- This proposal will force a new PR review and Interop

 
MG: This is not a technical
argument against the proposal. The TC always planned on a  second
PR review and it’s up to the TC whether or not we really need another
round of interop.

- This proposal does not address any new features or use-cases

 
MG: I agree. It fixes
a part of the spec that did not work as designed. It also clearly describes
the feature and what it is intended to. I see that as an improvement over
the current spec.
DUG: Which parts of
the current spec do not work?  Making wild claims like this need to
be proven.

Legend: 
MC = MakeConnection 
MP = MessagePending 
CS = CreateSequence 

Specific comments: 
- Lack of support for multiple endpoints per Sequence.
  When a MC is received the receiver can determine which Sequence
  is being targeted by the ref-p's of the incoming message. However,
  not all messages being sent on that Sequence can be received by
  all anon endpoints.  How can the receiver of MC ensure that
the 
  proper message (e.g. response) is given to the proper anon endpoint?
  Ability to share RM state does not equate to share of messages.

 
MG: I think you are mixing
two different scenarios here. 
1) Support for using a
single sequence to and from multiple endpoints. The proposal I made certainly
supports this.  
DUG: This isn't an
answer. Please show how it works with your proposal.  I think concrete
message flows are needed.

2) Support for querying
a endpoint for specific messages. This is not needed to support 1, nor
is it needed for any RM scenario. Which unreachable endpoint receives and
processes a given message and when it does so are implementation problems
in the Client RMD and part of its contract with the applications that use
it.
DUG: Again, not an
answer.  Please show how two anon clients can be assured that when
they turn on RM and use your MC proposal they will each receive the correct
response.  Saying that's an implementation problem is not only not
answer but leaves things wide open to interop problems.  Please show
the message flows for how this would work.

- Restrictions on RM Processing model.
  Base specifications should, within reason, try to avoid restricting
the 
  usage pattens under which they are used.  Since the RM spec
is silent on 
  algorithm used to determine when (and how many) Sequences are used
we need 
  to be careful about adding things to the spec that would restrict
the 
  impl's choices.  Above we talk about a single Sequence spanning
multiple 
  endpoints, but going the other direction there may be RM processors
that 
  choose to group messages destined to the same endpoint under one
Sequence. 
  In essence what we're talking about grouping based on wsa:To.  This
proposal 
  would not allow for this type of processing model because all wsa:To
values 
  would be the WSA Anon URI.

 
MG: This is an implementation
style argument and I don’t see a scenario here. However, this can be accomplished
by the server returning a MP header with an appropriate EPR and the unreachable
endpoint occasionally sending an empty MC to that EPR. 
DUG: Please show how
grouping by wsa:To is achieved because I just don't see how a MP header+an
EPR solves it.  Please show concrete message flows.

- How many MC messages are needed?
  This proposal would require one MC per Sequence. If there are multiple
  Sequences at play between the two endpoints the current spec allows
  for a single MC to pull back messages from any Sequence. This could
be 
  a significant performance issue.

 
MG:  Both proposals
require one MC per Sequence. The only difference is that in this proposal
one MC is for a specific Sequence; but the same number of messages are
exchanged. There is not an issue here.
DUG: Not true. This
proposal requires one MC per Sequence - which means if there are two active
Sequences then there MUST always be two MC's sent - in the current spec
only one MC is needed.  Yes one MC per message is needed, but if there's
nothing to pull back then this proposal is quite a bit more chatty and
far less optimal.

- Since MC is an optional feature, how does the receiver know it will be
used? 
  Here there are two reasons the receiver of the MC would like to
know 
  whether or not MC will be used at all. First, the receiver may choose
to 
  reject requests to use the anon EPR if MC will not be used - thus
saving 
  resources.  Second, in cases where RM is optional for messages
targeted 
  to the Anon EPR, if the receiver knows that MC will not be used
it may 
  choose to not turn on RM at all, thus allowing normal WSA rules
to 
  apply to its delivery.  This would still allow a non-MC enabled
client 
  to function, where if the receiving end assumed that MC were always
  an option it may never actually deliver any message until a MC is
sent. 
  Thus never sending any messages.

MG: The receiver can fault
on receipt of MC if it wished to, so the first point above isn’t an issue.
The second point does not have a clear use case. Why would an endpoint
turn off RM if it knew MC wasn’t going to be used? That sounds like this
is no longer an RM scenario. My proposal does not cover using MC for non-RM
messages. I don’t understand how the current spec would address what you
just described either.
DUG: This issue is
about cases where MC is not used so I don't understand your statements
at all.  How can it fault on a MC that is never sent? The RMD may
choose, at run-time by examining the replyTo of the request, to decide
whether or not to use RM at all for the responses. You keep forgetting
about cases where RM is available but optional.  So, the RMD may turn
off RM and just use WSA rules because it just doesn't want to support MC
at all - would have thought you, of all people, would want this option
:-)  

  Also, if the receiver of the MC makes the wrong choice (meaning
it thinks 
  MC will not be used) and MC's do flow then a new (unused) Sequence
will 
  be created. 
 
MG: If you are not expecting
an MC why would you create a sequence instead of just faulting?
DUG: Because your proposal
says that when an MC flows to an unknown AcksTo EPR or to the Server EPR
it means the client wants a new Sequence - according to your proposal what
else can the RMD do but create a new Sequence?

- Requires special AcksTo EPR construction.
  While obviously its possible to create AcksTo EPRs with distinguishing
  ref-p's, w/o this proposal there is no need to.  All RM protocol
  messages have a wsrm:Identifier already that is used to identify
which 
  Sequence is at play.  This would require a secondary mechanism
to also 
  be used.  While not a deal-breaker it is a duplication of function
and 
  forces exposure of the MC feature into the other RM aspects.  Current
  version has no impact the rest of the RM spec - thus when this RM
  feature is turned on it doesn't require a change to the rest of
the RM 
  stack. 
MG: The current MC also
has distinguishing information in it separate from the wsrm:Identifier.
I do not see an issue here.
DUG: Not true.  Sequence
based MC uses RM's SeqID.  Since the MC+URI variant isn't based on
pulling by RM sequence it doesn't need to worry about this.  This
proposal dups things unnecessarily and trying to point the finger some
place else doesn't change the issue.

- The AcksTo is not the same thing as the RMS.
  Implicit in this proposal is that the AcksTo endpoint has access
to all 
  of the same information as the RMS - which is not necessarily true.
The 
  AcksTo EPR is not required to do anything more than be able to update
the 
  state of the RM Sequences w.r.t. Acks - nothing more.  This
is one of the 
  reasons we have a dedicated AcksTo EPR at all - otherwise we would
have 
  just overloaded an existing EPR - like wsa:ReplyTo or wsa:From.
Using the 
  AcksTo EPR for this purpose is forcing a certain implementation
choice. 
MG: There was a lot of
discussion on last week’s call of sending protocol faults to the AcksTo
EPR as they were protocol control messages. So this EPR is already overloaded.
I think the MC is another type of protocol control message so I don’t
see a problem here either. That said, I’m open to seeing a new MC EPR
defined.
DUG: Yet another change
to the base RM protocol needed to support this proposal.

- Orphan AcksTo 
  This proposal suggests that a MP header may contain an AcksTo EPR
as a 
  signal that the receiver of the MP should then send a MC to that
EPR 
  as a mechanism by which new Sequences can be created.  This
would then 
  create an 'orphan' AcksTo EPR.  This EPR is not associated
with a 
  Sequence, thus its an orphan, and quite a change to how RM works.
  Or if it is associated with a Sequence then what is the state of
that 
  Sequence?  This would imply that a Sequence is created before
a CS is 
  actually processed. 
 
MG: Reusing the AcksTo
EPR from the MP in the CS that flows back would solve this. I don’t really
see an issue here either.
DUG: Again, you're
creating an AcksTo EPR w/o creating a Sequence - this goes against the
current RM model - of course there's an issue here. 

- MP on nonexistent message.
  This proposal talks about a MP being able to flow so that the sender
of 
  message can signal to the anon endpoint that a MC needs to be sent
so a 
  CS can flow.  But in cases where this is the first message
being sent 
  how can this work? There is no back-channel from the anon endpoint
to 
  send it on.  Also, even if there was some incoming message
how did 
  the sender of the MP who which anon endpoint sent it? There is no
identifying 
  info in the message to distinguish one endpoint from another.

MG: The unreachable endpoint
can poll with empty MCs.
If the receiver of MCs
receives an empty MC with no other identifying headers  (e.g. no previously
communicated ref-params) then the sender of the MC is truly anonymous and
the response to the MC will include a CS and information that will make
the unreachable client identifiable in the future.  This is a non-issue.
DUG: I need a concreate
message flow example here because this makes no sense.  If there is
no message going back there's nothing to piggy-back the MP onto.  How
does the client know to send a MC at all?  If there are multiple clients
how does the RMD know which new/empty-MC coming in is related at all to
an existing request/response MEP.  All of these "this is a non-issue"
type of responses makes it clear to me that you haven't thought about this
from an implementation point of view because there are just too many unknowns
or assumptions going on here.

- Poor performing CreateSequence
  When the sending endpoint needs to use MP to create new Sequence
we see 
  the following message exchanges:
  Client -> some msg           -> Server
  Client <- some msg+MP/AcksTo <- Server
  Client -> MakeConnection     -> Server/AcksTo
  Client <- CreateSequence     <- Server/AcksTo

  vs current solution:
  Client -> MakeConnection -> Server
  Client <- CreateSequence <- Server

MG: This is not correct.
My proposal allows for polling for the CS with MC as well, so the minimal
exchange in both cases is exactly the same. I see the first form above
as a distinct advantage of my proposal over the current form in that it
allows the server side to set an explicit relation between previously received
messages and messages over a newly established sequence.
DUG: Please show how
this works when there are multiple clients talking to the same server.
 Above you said that the RMD can fault on the receipt of a MC if it
wants to - so relate that to this scenario.  The RMD gets new MC's
from unknown/anon clientts how does it know which should get back a CS
and which should get a fault?  There is no correlating info at all.
 The only possible way I saw it working is how I showed it above so
I don't see how your claim holds up.

  As stated in the previous bullet, there's no guarantee that the
"some msg" 
  data is actually available to do that msg exchange, but also this
  proposed solution is quite a bit more verbose and non-optimized.

- Unreliable-in/Reliable-Out not supported.
  Client sends a GetQuote, ReplyTo=anon.  Server decides to use
RM to 
  send the response.  How can this work?  The proposal implies
that 
  either a CS or a MP is sent back but how and on what socket?

 
MG: No, the proposal is
clear. It sends a MP on the backchannel triggering the client to respond
with the MC to get the CS.
DUG: there is no back-channel
to send it on. please show concrete message flows to show how this works.


  Anon replyTo means the only thing that can flow back on the current
  sockets is the GetQuoteResponse so how does the CS flow?
  Anon doesn't allow the GetQuoteResponse to flow back on any other
  socket than the one carrying the request.  Some people argue
that it 
  can if we're in the error case (broken socket) and using RM, but
what 
  about the non-error case - socket is still there and waiting for
a 
  response?  WSA rules would still need to apply.  Or are
we suggesting 
  this proposal changes WSA processing rules?

 
MG: If this is a true
req/resp WSDL then how does the current spec address this? That the server
violate its own published contract at its whim? I would argue that if you
are expecting a reliable response you need to establish the inbound sequence
to handle it before you invoke that operation. There isn’t a good way
to handle the error case otherwise.
DUG: current spec works
just fine because we don't use the WSA anon URI and we clearly define the
semantics of the new URI.  This proposal violates WSA's definition
of anonymous.  Concrete message flows are needed to prove that this
works in your proposal.

- Places burden of creating new sequences on the wrong side.
  There are scenarios mentioned in this proposal where the RMD sends
a 
  MC to, in essence, ask for a CS to flow.  This is quite a change
to 
  the current RM processing model where its the RMS that is always
in 
  control over when to create new Sequence.  Also, this then
leads to 
  the question of how did the RMD know a new Sequence is needed?

 
MG: In both proposals
you have to poll with MC.
DUG: This isn't an
answer.  Your proposal says there are times when the client wants
a new Sequence for the inbound messages - how does it know this? 

- Client Identification 
  Following on the previous comment, the proposal says:
    When an unreachable client requires a new inbound sequence
it MAY 
    send the MakeConnection header independently to RM service
endpoint. 
    Upon receipt of a MakeConnection header block that the RM
Source 
    cannot relate to an existing sequence it MUST respond with
either 
    a CreateSequence message on the protocol specific back channel
    of the request, or with a MakeConnectionRefused fault. 
  How does the service know if a Sequence already exists? What unique
  info is there to compare?  
 
MG: If the MC previously
returned identifying ref params it can identify the sender. There is not
an issue here.
DUG: This doesn't solve
it.  How does the MC return identifying ref-p's that are specific
to a sender when it has no idea if its seen a particular sender before?
 There is nothing to distinguish one anon client from another.
 
Since these MC's can be delayed in
the 
  network, its possible that many may be sent and thus lots of 
  CreateSequences may flow - meaning lots of unused Sequences may
be 
  created.  See next point.


- Unnecessary Sequences/Message flows.
  Since we're talking about RM here we need to think about what happens
  in cases where messages are late to the party.  In this proposal
if a 
  rogue MC is received and the AcksTo EPR it pointed to is for a terminated
  Sequence then a CS will flow back.  This will cause an unused
Sequence 
  on both endpoints and cause the generation of unused MC's that will
  continually flow until the Sequence expires.  And worse, what
if the 
  CS had an Offer - we then double the number of unused Sequences.

 
MG: If the AcksTo is for
a terminated seq then a fault can always be returned. This is an implementation
detail.
DUG: "Can"?
 Once a seq is terminate the state data may be gone - per your proposal
the RMD has no choice but to create a new sequence.  Again, this means
that lots of unused sequences will be created unless there's some special
magic around that allows the RMD to know more than what you're specified
in your proposal.  

- MP sent to unidentified client
  The proposal says that a MP can be sent on inbound traffic to the
  unreachable endpoint, but it doesn't link the MP header to the 
  client or to the Sequence so how does the sender of the MP know
  whether or not any particular message can carry the MP header.

 
MG: The MP can be related
to the sequence of the RM message it is piggy-backed on.
DUG: This doens't answer
my question so again please show concrete message flows to prove this works.

- MP & client id again 
  The proposal says: 
    In the circumstance where an RM Source wishes to initiate
a sequence 
    with an anonymous client, the RM Source MAY return a MessagePending
    header over an existing transport backchannel. The MessagePending
    header MAY contain an AcksTo EPR...
  How does the RMS know which anon client its talking to?

MG: The MP can be related to the sequence of the RM message it is piggy-backed
on.
DUG: there is no sequence
so this non-answer makes no sense. 

Misc: 

Some pointers to old discussions:
Discussion if i089 at Raleigh f2f:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17492/MinutesWSRX-f2f-032306.html#_Toc131830356

Old proposal for i089 but the word doc contains a lot of the rationale
behind the thinking: 
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200605/msg00123.html

Pointer to i010, which dealt with Sequences spanning multiple endpoints:
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i010

thanks 
-Doug