Subject: [Rserpool] comments on draft-ietf-rserpool-asap-03

From: Harrie Hazewinkel <[email-masked]>
Date: Mon, 06 May 2002 20:43:47 +0200

HI,

Some comments;

1) The first paragraph of the abstract equals that of the
introduction.

2) The abstract has references and short cuts of the terms.

3) The following

'>' indicates portions of the original text of the draft.
> Abstract
>
>     Aggregate Server Access Protocol (ASAP) in conjunction with the
>     Endpoint Name Resolution Protocol (ENRP) [ENRP] provides a high

A reference in the abstract.
Although I understand the close relationship between ASAP and ENRP,
I think it is weird that one here directly uses ENRP. This document
is about ASAP.

>     availability data transfer mechanism over IP networks. ASAP uses a
>     name-based addressing model which isolates a logical communication
>     endpoint from its IP address(es), thus effectively eliminating the
>     binding between the communication endpoint and its physical IP
>     address(es) which normally constitutes a single point of failure.
>
>     In addition, ASAP defines each logical communication destination
>     as a pool, providing full transparent support for server-pooling
>     and load sharing. It also allows dynamic system scalability -
>     members of a server pool can be added or removed at any time
>     without interrupting the service.
>
>     ASAP is designed to take full advantage of the network level
>     redundancy provided by the Stream Transmission Control Protocol
>     (SCTP) [SCTP].

Not sure if the above is needed in the abstract, since also ASAP could
potentially run over UDP or TCP.

> Each transport protocol to be used by Pool
>     Elements (PE) and Pool Users (PU) MUST have an accompanying
>     transports mapping document.

What is a transport mapping document??

> Note that ASAP messages passed
>     between PE's and ENRP servers MUST use SCTP.

Is SCTP really a must?? The architecture document shows also TCP variants.

>
>     The high availability server pooling is gained by combining two
>     protocols, namely ASAP and ENRP, in which ASAP provides the user
>     interface for name to address translation, load sharing
>     management, and fault management while ENRP defines the high
>     availability name translation service.
>
> Table Of Contents

The ToC needs some adjustments in the alignment of the page numbers.

[..]
>
> 1. Introduction
>
>     Aggregate Server Access Protocol (ASAP) in conjunction with ENRP
>     [ENRP] provides a high availability data transfer mechanism over IP
>     networks. ASAP uses a name-based addressing model which isolates a
>     logical communication endpoint from its IP address(es), thus
>     effectively eliminating the binding between the communication
>     endpoint and its physical IP address(es) which normally constitutes
>     a single point of failure.

This is equal as in the abstract.

>
>     When multiple receiver instances exist under the same name, a.k.a, a
>     server pool, ASAP will select one Pool Element (PE), based on the
>     current load sharing policy indicated by the server pool, and
>     deliver the message to the selected PE.

I know the arch-doc gives more basics, but a little bit
of describing what server pooling is and what is ment by load sharing
would be appropriate.

>
>     While delivering the message, ASAP monitors the reachability of the
>     selected PE. If it is found unreachable, before notifying the sender
>     of the failure, ASAP can automatically select another PE (if one
>     exists) under that pool and attempt to deliver the message to that
>     PE. In other words, ASAP is capable of transparent fail-over amongst
>     instances of a server pool.
>
>     ASAP uses the Endpoint Name Resolution Protocol (ENRP) to provide a
> high     availability name space.  ASAP is responsible for the
> abstraction of     the underlying transport technologies, load
> distribution management,     fault management, as well as the
> presentation to the upper layer     (i.e., the ASAP user) a unified
> primitive interface.
>
>     When SCTP [RFC2960] is used as the transport layer protocol, ASAP can
>     seamlessly incorporate the link-layer redundancy provided by the
>     SCTP.
>
>     This document defines the ASAP portion of the high availability server
>     pool. ASAP depends on the services of a high availability name space
>     a.k.a. ENRP.
>
> 1.1 Definitions
[..]
>
>     Operation scope:
>     Server pool (or Pool):
>     Pool handle (or pool name):
>     Pool Element (PE):
>     Pool User (PU):
>     Pool Element handle (PE handle):
>     ENRP server:
>     Home ENRP server:
>     ENRP client channel:
>     ENRP server channel:
>     ENRP name domain:
>     Network Byte Order:
>     Transport address:

Are the above definitions not for the arch document or the
enrp document.

>
>
> 1.3 Scope of ASAP
>
>     The requirements for high availability and scalability do not imply
>     requirements on shared state and data. ASAP does not provide
>     transaction failover.  If a host or application 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. ASAP MAY provide hooks to assist an application in
>     building a mechanism to share state but ASAP in itself will NOT
>     share any state.

This all tells things of NOT. But what is the scope of ASAP.
Everything else one can imagine?? :-))
>
>
> 1.3.1 Extent of the Namespace
>
>     The scope of the ASAP/ENRP is NOT Internet wide.  The namespace is
>     neither hierarchical nor arbitrarily large like DNS.  We propose a
>     flat peer-to-peer model.  Pools of servers will exist in different
>     administrative domains. For example, suppose we want to use
>     ASAP/ENRP.  First, the PU may use DNS to contact an ENRP server.
>     Suppose a PU in North America wishes to contact the server pool in
>     Japan instead of North America. The PU would use DNS to get the list
> of     IP addresses of the Japanese server pool domain, that is,
>     the ENRP client channel in Japan. From there the PU would query the
>     ENRP server and then directly contact the PE(s) of interest.
>
[..]
> 2. Message Definitions
>
>    All messages as well as their fields described below shall be in
>    Network Byte Order during transmission. For fields with a length
>    bigger than 4 octets, a number in a pair of parentheses may follow
>    the filed name to indicate the length of the field in number of
>    octets.
>
> 2.1 ASAP Parameter Formats
>
>    The basic message format and all parameter formats can be found
>    in [ENRP-ASAP].

Now I really start to wonder (like my comment on the architecture)
iwhy not combining the ASAP and ENRP protocol. As a result the
semantics of the application element above the protocol layer
of the combined ASAP and ENRP protocol the types of requests
and responses allowed.

Also if you look a bit further (section 2.2) one sees that even the
message types of both protocols are in the same enumeration.

> Note also that ALL ASAP message exchanged between
>    the ENRP server and either a PE or PU MUST user SCTP.

What is the reason for this MUST. Maybe it is wise to add this.

> PE to PU
>    data traffic MAY use any transport protocol specified by the PE
>    during registration.
>
> 2.2 ASAP Messages
>
>    This section details the individual messages used by ASAP. These
>    messages are composed of a standard message format found in
>    Section 4 or [ENRP-ASAP], elements and parameters. The parameter
>    descriptions may also be found in Section 3 of [ENRP-ASAP].
>
>
>    The following ASAP message types are defined in this section:
>
>       Type       Message Name
>       -----      -------------------------
>       0x00       - (reserved by IETF)
>       0x01-0x06  - defined by [ENRP]
>       0x07	 - Registration
>       0x08       - Deregistration
>       0x09       - Registration Response
>       0x0a       - Name Resolution
>       0x0b       - Name Resolution Response
>       0x0c	 - Name Unknown
>       0x0d       - Endpoint Keep Alive
>       0x0e	 - Endpoint Keep Alive Acknowledgement
>       0x0f	 - Endpoint Unreachable
>       0x10	 - Server Hunt
>       0x11	 - Server Hunt Response
>
>
> 2.2.1 REGISTRATION message

For all these message types. GIve first a small description of
what that message type is supposed to do. For instance,

'The REGISTRATION message is to be used for registering a pool element
in the server pool.'

It provides a more easy access to the message types.

Provide the information of the elements of the message format in a
list form (preceded by for instance a '*' or '-').

Add special notes or semantics after that (I do not mean here procedures of 
use).

Going through the list of message types I see some are done so, some only
with a small description,....

[...] (here I stopped)

Harrie

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