Subject: [Rserpool] Issues for architecture draft, asap draft

From: Phillip Conrad <[email-masked]>
Date: Mon, 17 Mar 2003 16:17:38 -0800

Some suggestions regarding latest versions of the architecture draft and 
ASAP drafts

first: http://www.ietf.org/internet-drafts/draft-ietf-rserpool-arch-05.txt

(a) Section 2.2.3, Figure 1

The figure indicates SCTP as the transport protocol over which ASAP 
operates for PU<->NS communication.   A mention should be added that this 
communication may also take place over TCP (following the protocol 
specified in 
http://www.ietf.org/internet-drafts/draft-conrad-rserpool-tcpmapping-01.txt)

Note that the figure in 2.2.4 (which has no figure number) is correct in 
indicating only SCTP.

(b)  Section 2.2.5, PU <-> PE Communication

Based on current direction to simplify the protocols, avoiding multiple 
transport registrations, this section should be updated as follows:

An application can interact with an RSerPool implementation in one of two ways:

   (1) a multiplexed control/data channel, where the data channel is 
accessed through RSerPool primitives, where this multiplexed data/control 
channel is one of only two options: (a) a single SCTP association, with 
control/data separated by PPID or (b) a single TCP connection, with 
control/data separated by PPID via the TCP mapping layer described in 
http://www.ietf.org/internet-drafts/draft-conrad-rserpool-tcpmapping-01.txt

   (2) a data channel with NO control channel, where the data channel is 
provided by a transport protocol directly, and is NOT accessed through 
RSerPool primitives.    Note that certain enhanced failover services (e.g. 
business cards, state cookies, message failover) are not available when 
this method of interaction is used.

Note that for a given pool, since a fundamental principle of RSerPool is 
that all PEs provide equivalent service, all PUs and PEs should make the 
same choice for the style of interaction between the applicaiton layer and 
the RSerPool layer: that is, for a given pool, either all PEs and PUs in 
that pool use a multiplexed control/data channel for PE-PU communication,, 
or all PEs and PUs in that pool use a data channel only for PE-PU 
communication.

When the multiplexed control/data channel is used, enhanced failover 
services may be provided, including:

    o  The PE can send a testament (business card) to the PU for providing 
information to
       which other PE the PU should failover in case of a failover.

    o  The PE can send cookies to the PU. The PE would store only the
       last cookie and send it to the new PE in case of a failover.

etc...

(c) 2.3.2 Cookies

"Cookies may be sent from the PE to the PU if the PE wants this to do."

Minor grammar point: "wants to do this"  would sound more natural in 
English. :-)

(d) 2.3.1 vs. 2.3.3... are business cards and testaments the same or 
different concepts?
If they are the same, we should adopt one term or the other.  I like 
"testament" as a good metaphor for the idea of "this is what to do in case 
of my death".  Also, check spelling of "szenario."

now, Comments on 
http://www.ietf.org/internet-drafts/draft-ietf-rserpool-asap-06.txt

(e) In section 4.3, 4.4

cache.populate.request([Pool-Handle |Pool-Element-Handle])
cache.purge.request([Pool-Handle | Pool-Element-Handle])

    Can you help clarify the role and purpose of these from the standpoint 
of the user application code.. are these called
    by the PU? by the PE?    Are they really user service primitives, or 
are they operations that are internal to the PU/PE in response to certain 
message types, but not directly accessible to the user?  An example use 
case might be helpful.

(f) Section 4.5.4.   We have an opportunity to clarify an issue that may be 
a little fuzzy right now: how does a PE "respond" to a message from a PU 
(particularly if that PU is _not_ a PE in any pool).    The easiest way to 
imagine this happening is that when the PE receives a 
data.received.notification, that notification contains either the transport 
address of the PU, or some handle that ASAP can use to refer to that 
address.    The PE then uses the "data.send.request" primitive as per 
section 4.5.4 to transmit the "reply" back to the PU that originated the 
message.

Of course, the actual API may look quite different from this... e.g. the 
"handle" might be the file descriptor that points to a particular SCTP 
association or TCP connection, etc.   but _conceptually_, the 
data.send.primitive by transport addresss is how the PE gets the message 
back to the PU.   And this is something that is a bit mysterious in the 
current versions of the drafts, and which I think we should clear up.

_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 18 Mar 2003 18:32:13 -0600

Hi, Phill,

I agree with your comments in general. Just a few minor additions. Pls
see in-line.

regards,
-Qiaobing

Phillip Conrad wrote:
...
> http://www.ietf.org/internet-drafts/draft-conrad-rserpool-tcpmapping-01.txt

ok

> RSerPool primitives.    

Maybe we should note that if so desired an implementor is of cause still
allowed to build a unified API to handle ASAP messages and user data,
even though the ASAP layer in this case will not touch the user data. 

> Note that certain enhanced failover services (e.g.

Message failover is independent to the existence of a control channel.
Think about the simple case where a PU sends user data to a pool over
SCTP with no control channel. The PU in this case can still enjoy a good
degree of message failover service by using features provided by SCTP
(e.g., ASAP layer in the PU will always be able to re-send to an
alternate PE any un-sent/un-acked messages kicked back by the SCTP assoc
to the failed PE).

How about we change the text to:

====
   (2) a data channel with NO control channel, where the data channel is 
provided by a transport protocol directly, and is NOT accessed through 
RSerPool primitives (Note, an implementor can of cause still choose to
use a unified API to handle ASAP and user messages in his/her
implementation). Note that certain enhanced failover services (e.g.
business cards, state cookies) are not available when this method of
interaction is used.
====

>        last cookie and send it to the new PE in case of a failover.

Ok.

...
> of my death".  Also, check spelling of "szenario."

I think the new buz card can be considered to contain the info "I am a
member of pool X". In Randy's old definition, buz-card = new buz-card +
testament. I wouldn't disagree if we want to move back to Randy's old
definition. In that case, we would only need one def. Either way will be
fine with me.

>     by the PU? by the PE?    

By the PU.

> Are they really user service primitives, or

I think they are both user primitives. cache.populate.request is called
whenever the user desires to refresh or pre-fetch the info of a pool
handle in its local cache. cache.purge.request is used by the user to
"forget" a pool (so that when it sends to the same pool next time a
fresh query is guaranteed to occur).

> section 4.5.4 to transmit the "reply" back to the PU that originated the

Yes. 

> association or TCP connection, etc.   

agreed.

> but _conceptually_, the

Or a "reply-to-sender" primitive (like in the case of a HTTP server, the
response is sent back to where the query comes from). Of cause, as you
pointed out, the detail is up to the API designer.
_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 18 Mar 2003 18:32:13 -0600

Hi, Phill,

regards,
-Qiaobing

Phillip Conrad wrote:
...

ok

====

Ok.

...

By the PU.

Yes. 

agreed.

---

From: Phillip Conrad <[email-masked]>
Date: Wed, 19 Mar 2003 00:04:36 -0800

Some replies to a subset of your comments inline (the omitted ones are 
places where we are generally in accord)

>even though the ASAP layer in this case will not touch the user data.

I agree to the extent that what you indicate is true... an API could 
certainly be built that way.   On the other hand, I wonder why you feel 
this needs to be noted.   My sense is that in the first of these two modes, 
a unified API is required, and in the second mode, a unified API, while it 
could be built, adds no value whatsoever.

   When you are in "mode one", you certainly are sending all your user data 
messages through a unified RSerPool (ASAP) API.

But when you are in "mode two", there really aren't any ASAP messages 
except between PU and ENRP server.   So, why would it make sense to build a 
unified API, especially if that API just ends up being a straight pass 
through for the native transport protocol API?  It seems like a waste of 
time, particularly since part of the point of mode two is to allow "any 
arbitrary transport"to be used.   Any "unified API" you build would 
necessarily limit the underlying transports to the ones that unified API is 
designed to support.

Perhaps  I am not clear on your meaning.

In any case, I'm not sure if the ASAP draft is the right place to make this 
note...  perhaps it should go in the API draft instead.  However, on this 
point I only have a "concern", not a strong objection.   I would defer to 
the lead author of the ASAP draft to decide which way to go here; perhaps 
he will perceive your intent more clearly than I. :-)

  In any case, if it doesn't make it into the ASAP draft, we can 
certainly  note it in the API draft.

>business cards, state cookies) are not available when this method of

OK, now I think I see where you are going with this.  You want to failover 
user messages, even when we are in mode two (perhaps, for example, UDP or 
DCCP messages).

You are right, of course, that we do not need a control channel in order to 
be able to failover user messages.. only a unified API that understands 
multiple transports.

I'm concerned that this is a slippery slope to extra complexity, something 
we are trying to get away from.   But we can try to accommodate this... 
perhaps it will not be as complex as I fear.   Let me think about it, and 
see if I can write some text that will take your wishes here into account.

...
>fresh query is guaranteed to occur).

Ok.. thanks.. that explanation helps.    We may want to include some text 
like that in the draft to clarify this.

...

Thanks for reading and providing thoughtful comments!

Best Regards,
Phill

---

From: Phillip Conrad <[email-masked]>
Date: Wed, 19 Mar 2003 00:04:36 -0800

...

...

Best Regards,
Phill

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 19 Mar 2003 15:38:18 -0600

Hi, Phill,

Please see my comments in-line.

Phillip Conrad wrote:
.....
> could be built, adds no value whatsoever.

I think we are in general agreement here. I guess my intention to have
this noted is to avoid give the reader the wrong impression that two
different styles of implementation are required to use the two operation
modes. 

In fact, the most likely (and also the highly recommended, IMHO)
implementation scenario should be to have a single Rserpool stack with a
single "socket-like" API. And the same stack and API should always be
capable of supporting both modes. It is only when a PU or PE app is
built on top of this common stack, based on the nature of the
application, the app developer then make the choice of whether to use a
control channel or not (in fact the PU or PE may even make this choice
dynamically based the current sys configuration). In such a scenario, it
would be more nature and easier to me that the same unified API would be
used no matter whether or not a control channel is used. On the other
hand, to make the app use a unified API when control channel is used but
a separate API when no control channel is used of cause is do-able, but
it may turn out to be a more complicated implementation approach.

> necessarily limit the underlying transports to the ones that unified API is

ditto.

> certainly  note it in the API draft.

Either place would be fine, as long as the intention is worded in a
consistent way.

> be able to failover user messages.. only a unified API that understands

yes. We always assume the ASAP implementation would be able to handle
this.

> see if I can write some text that will take your wishes here into account.

I think it is not complicated. As we talked about at the meeting, we
should always remind the implementor to build a full stack capable of
operating in both modes. We should discourage them to build incomplete
stack that only do a subset of Rserpool.

regards,
-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 19 Mar 2003 15:38:18 -0600

Hi, Phill,

Phillip Conrad wrote:
.....

ditto.

regards,
-Qiaobing