Subject: [Rserpool] draft-conrad-rserpool-service-03.txt

From: Harrie Hazewinkel <[email-masked]>
Date: Fri, 21 Mar 2003 18:01:14 +0100

HI,

Some comments on your draft. I do sent these to the WG-list,
since it looks like this private submission is (or becomes)
work of the WG.

Overall, I believe this document could be integrated with the
architecture document. What would the WG think of this??

Im also believe that here and there the text can be improved.
I know it is work in progress, but still. Some of my main points
are below.

Harrie

> Abstract
>
>    RSerPool [1] is a framework to provide highly available services

Is 'highly available' changed into 'high availability' not better??
In other documents and the RFC 3237 speak of 'highly reliable'.
(multiple times in the document)

>    between clients and servers.  This is achieved by grouping servers
>    into pools, each with an identifier and pooling policy.  Three
>    classes of entities are defined: Pool Users (clients), Pool Elements
>    (servers), and Name Servers.

I believe the first usage of 'clients and servers' is misleading
in association to the last usage where 'clients' and 'servers'
are used as text replacement for 'Pool Users' and 'Pool Elements'.
I would suggest to delete 'between clients and servers'.
I beleive, 'clients' and 'servers' are not the well-known definitions
in this document.

>    This memo defines the services provided by this framework to upper
>    layer protocols and applications for Pool Users and Pool Elements.
>    It describes the service primitives that the framework provides and
>    describes example scenarios.
>
>    It also describes the requirements for mapping (or adaption or
>    "shim") layers for a variety of transport protocols (SCTP, TCP, or
>    others) such that upper layer protocols and applications may use a
>    common framework/API to utilize the services provided.

The above sentence seems grammatically not correct. (not native 
speaker).

> 1. Introduction
>
>    The Reliable Server Pooling architecture is defined in [1].  The
>    architecture provides highly available services by defining three
>    classes of entities: pool users (clients), pool elements (servers),
>    and name servers.  Pool elements are grouped into server pools and
>    can be used by pool users via its pool name (or "handle") and can be
>    selected by following the pool's pool element selection policy.

Why only mentioning 'Pool elements' more detailed. I suggest to do the 
same
for the pool users and name servers. This is maybe a little bit 
repeating
from other documents, but as introduction a small description would 
suffice.

>    Utilizing a limited set of RSerPool services provides the capability
>    for legacy upper layer software to use a few RSerPool services with
>    relatively minor modifications, and allows a broad range of
>    underlying transport protocols to be supported.  To achieve a richer
>    and more complete failover model, however, a majority of the 
> RSerPool
>    services should be used, which places certain requirements and
>    restrictions on the transport layers that can be supported.

Would it not be usefull to define compliance statements for this.

>
>    Note that regardless of the number of service primitives actually
>    utilized by any given upper layer protocol, this document assumes
>    that the upper layer protocol/application is operating on a platform
>    that has a full running, implmentation of ASAP.
                                  ^^
'implmentation' -'implementation'

>
>    The following figure illustrates the protocol stacks when using the
>    RSerPool framework (Pool Element perspective shown).  Note that the
>    mapping layer MAY be a "NULL" layer, if no control channel is
>    utilized and/or the data channel is not utilized (e.g.  application
>    specific data).
>
>      +--------------------------------------+
>      |  Application/Upper Layer Protocol    |
>      +--------------------------------------+
>      |            RSerPool API              |
>      |(control channel) |  (data channel)   |
>      +------------------+--------+----------+
>      |         ASAP layer        |          |
>      +------------------+--------+          |
>      |        mapping/adaption layer        |
>      +------------------+-------------------+
>      |          transport protocol          |
>      +------------------+-------------------+

Provide a description of the functionality of the protocol stack.
Because of the lack of the small description I don't understand exactly
how the 'NULL' layer relates to the control channel as written in the
text before. It seems not stacked on top of each other.

>    The purpose of this document is to describe:
>
>    1.  the precise services provided by RSerPool to the upper layer,

Since there are more 'upper layer's,
'upper layer' -> 'Application/Upper Layer Protocol'.

>    2.  the tradeoffs in choosing which services to utilize,
>
>    3.  how applications must be designed for each of these services,
>
>    4.  how applications written over various transports (SCTP, TCP, and
>        others) can be mapped into these services.

I do not fully understand this. If I look at the previous stack,
there are always layers between the 'Application/...' and the transport
protocol. How could an application then be written for a
specific transport?

I also have the idea that 3. and 4. are the same. Or do you mean that 4.
is to described applications that were written directly on top of
a transport?

>
> 3. Example Application Scenarios

I believe it is weird that first examples of service usages are given 
and then
the services are defined. I suggest to move section 4. forward followed
by section 3. (of course renumber :-)
>
>    To illustrate the differences among an application without RSerPool,
>    an application using limited RserPool services, and an application
>    using a full suite of RSerPool services, this section provides an
>    informal description of how failover may be handled in each of these
>    cases.

Since I am not sure what the long term target of this document is, I
wonder about the text 'informal description'.

> 3.1 Example Scenario for Failover Without RSerPool
>
>    Consider a typical client/server application that does not use a
>    reliable server pooling framework of any kind.  Typically, the 
> server
>    is specified by a DNS name.  At some point, the application

'DNS name' -> 'hostname'

> 4.1 Initialization

'Initialization' -> 'Initialization Service'

> 4.3 Failover Callback Function

I would rename this into 'Failover Callback Function' -> 'Failover 
service'.
And as a result also change the section accordingly.

>
>    The charter of the RSerPool Working Group specifically states that
>    transaction failover is out of scope for RSerPool, i.e.  "if a 
> server
>    fails during processing of a transaction this transaction may be
>    lost.  Some services may provide a way to handle the failure, but
>    this is not guaranteed."  Accordingly, the RSerPool framework
>    provides a "hook" for applications to provide their own application-
>    specific failover mechanism(s).

Immagine you read the above in 10 years, why would I care about
the charter. I suggest delete it.

>       Business Card services:  when automatic failover is used, the
>       exchange of business cards for rendezvous services is
>       automatically performed by the RSerPool framework (e.g.  no
>       application intervention is required.

Is this not a seperate section??

>
> 4.5 Upper Layer/Application Level Acknowledgements
>

Should the acknowledgement not be part of the services?
>       ULP_ACK, responds to a received upper layer acknowledgement
>       request.

Is there no ULP_NACK? (not ACK)

> 4.6 RSerPool Managed Data Channel

'Channel' -> 'Service'

> 5.2.1 Mappings: Mandatory Requirements
>
>    These features MUST be present in any mapping of the RSerPool
>    framework mode to TCP (or any other transport protocol):

Why mentioning specifically TCP. Make it generic, since also
SCTP is used many times in RSerPool.
Example ->
These features MUST be present in any mapping of the RSerPool
framework to a transport protocol:

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

---

From: "Phillip T. Conrad" <[email-masked]>
Date: Wed, 02 Apr 2003 15:48:03 -0500

>since it looks like this private submission is (or becomes)

Yes, with the next submission, this will become an official working group 
document.   This was approved at the Atlanta IETF, but I have been slow to 
update the document due to the number of outstanding issues, as well as 
demands of my "day job".

>architecture document. What would the WG think of this??

This is something that has come up at both of the last two IETFs, and I 
think the consensus among document authors was that , yes, this is 
something we will consider before going to last call, but for now it is 
useful for pragmatic reasons to keep them separate.

>(multiple times in the document)

I agree: I like "high availabilty" better.  I'll make this change in the 
next pass unless there are strong objections.   I think that it might be 
good to consider adopting "high availability" in other places as well, 
since I think this gets more to the heart of the goal of RSerPool as I 
understand it than "highly reliable".

>I beleive, 'clients' and 'servers' are not the well-known definitions

I agree; adopting your first change, and striking the words "between 
clients and servers" makes the first sentence read:

"RSerPool [1] is a framework to provide high availability services."

I'm comfortable with that.

>The above sentence seems grammatically not correct. (not native speaker).

Good catch: I'm not sure whether it is grammatically incorrect, but I do I 
agree that it is hard to read and needs to be made more clear.

How about the following substitution?

This document also describe how to use the RSerPool framework on top of
a variety of underlying transport protocols, including SCTP, TCP and others.
In some cases, mapping (or adaptation or "shim" layers) may be required in
between RSerPool and the underlying transport.    This document specifies
requirements for these mapping layers.

>Why only mentioning 'Pool elements' more detailed. I suggest to do the same
>for the pool users and name servers. This is maybe a little bit repeating
>from other documents, but as introduction a small description would suffice.

Rather than providing more detail about "pool elements", my goal in this 
sentence was to briefly explain the concept of "server pool", "pool name", 
"handle", and "pool element selection policy".     However, I would be open 
to including a bit more introduction about pool users and name servers if 
you can suggest some text.

>>    and more complete failover model, however, a majority of the RSerPool

It might, though I'm not entirely sure what a "compliance statement" in 
this context would look like.  Can you suggest some text?

>'implmentation' -'implementation'

good catch.. I'll make a note to run the spell checker more carefully next 
time around.

>text before. It seems not stacked on top of each other.

I think we may end up scrapping this diagram altogether and redrawing it
showing two different cases, one for basic mode, and another for enhanced
mode.   I agree that some additional text will be needed to explain the 
diagrams more clearly.

>'upper layer' -> 'Application/Upper Layer Protocol'.

OK

>is to described applications that were written directly on top of

Suppose I were to change 3 to read "how new applications should be 
designed..." and change (4) to insert the word "legacy", so that it reads: 
"how legacy applications written over various..."

This was my intention, but I can see how it was not clear from the text.

>I believe it is weird that first examples of service usages are given and then

I think that the reason we didn't do it this way (and I think this may 
address some of your concerns below) is that one of the reasons for this 
document is to provide something that folks from various Application area 
working groups can read, and get a picture of whether RSerPool is something 
useful for their applications or not.

This is why we provide an "informal description" (per your comment below) 
of various scenarios before we get into a formal description of RSerPool 
services.  It is also one argument for keeping the document separate from 
the architecture, ASAP, ENRP and other documents, which are more dealing 
with the internal details of the technology.    The services document is 
intended to explain what the upper layer gets by sitting on top of 
RSerPool, and treating it, in a sense, as a black box that provides a 
particular set of services.

>wonder about the text 'informal description'.

(see comments above)

>>    reliable server pooling framework of any kind.  Typically, the server

OK... as long as we still  emphasize that DNS is being used to translate 
the hostname to an IP address, as contrasted with RSerPool translating a 
Pool Handle to a Pool Element Handle.   While parallels can be drawn 
between the two processes, we also want to emphasize the differences.

>'Initialization' -> 'Initialization Service'

OK

>I would rename this into 'Failover Callback Function' -> 'Failover service'.

Calling this "failover service" would be misleading, I think, because this 
"failover call back function" is only one component of the complete 
failover service, not the whole thing.     Other parts of the failover 
service are the message services associated with failover (including 
forwarding and/or retransmission to a new pool element, for example.)

However, I would be ok with calling it the "failover callback service", if 
it is helpful to have all the services have "service" in their name.

>>    transaction failover is out of scope for RSerPool, i.e.  "if a server

Good point: what does the WG think of the following text in its place?
(Note that this paragraph introduces the failover callback function,
possibly renamed as the "failover callback service").

Transaction failover is out-of-scope for the set of services provided by
RSerPool , i.e. if a server ails during processing of a transaction this
transaction may be lost.    Techniques to prevent such losses (such as three
phase commit) can be built on top of RSerPool, but are not part of the
RSerPool framework.   However, as a "hook" to assist
applications that want to build their own  recovery mechanisms, RSerPool
provides a failover callback service.

>Is this not a seperate section??

I agree that the placement here is awkward...  thanks for pointing that out.

>Is there no ULP_NACK? (not ACK)

We've decided to remove this as a service anyway, so this section will be 
gone in the next iteration.

>>4.6 RSerPool Managed Data Channel

Actually, I'd prefer "Services for RSerPool Managed Data Channel", since in 
fact, this section lists several service primitives.
Also, while we're on the subject, we need to make sure that the service 
primitives here, and the ones  in the ASAP draft are aligned with one 
another, something I plan to make sure we do on the next iteration.

>framework to a transport protocol:

I agree with your suggested alternative text here.

Overall, thanks for reading the document and providing some helpful comments.

Thanks,
Phill

---

From: "Phillip T. Conrad" <[email-masked]>
Date: Wed, 02 Apr 2003 15:48:03 -0500

OK

(see comments above)

OK

Thanks,
Phill