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