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