Subject: [Rserpool] Comments on architecture document -- last call

From: [email-masked]
Date: Tue, 19 Aug 2003 15:38:44 -0500

I read this carefully.  Here are my comments.

Non-nits:

2.2.1 Endpoint Name Resolution Protocol

   The name servers use a protocol called Endpoint Name Resolution
   Protocol (ENRP) for communication with each other to make sure that
   all have the same information about the server pools.

I'm concerned that this will spark a lengthy debate about synchronization of ENRP databases.  We can't guarantee instantaneous updates of the database and a perfectly synchronized name space.  How about something like:

   The name servers use a protocol called Endpoint Name Resolution
   Protocol (ENRP) for communication with each other to exchange information and updates
   about the server pools.

2.2.2 Aggregate Server Access Protocol

   ASAP in conjunction with ENRP provides a fault tolerant data transfer
   mechanism over IP networks. 

I'm concerned that this will be interpreted as a general feature with some sort of guarantee.  It is only offered by use of specific services described in services document.  In other words, this will imply that it offers transparent fail-over in all cases which is not true.  Even with that, there is no guarantee of uninterrupted service.  It is best effort.  I would delete this sentence or talk about services and different possibilities.  These are discussed in the services document.

   In addition, ASAP defines each logical communication destination as a
   server pool, providing full transparent support for server-pooling
   and load sharing.

I don't understand this statement.  What is a logical communication destination?  

ASAP is also used by a server to join or leave a server pool.  It
   registers or deregisters itself by communicating with a name server,
   which will normally the home NS.  

see changes below:

ASAP is also used by a PE to join or leave a server pool.  It
   registers or deregisters itself by communicating with a name server,
   which will normally be the home NS.  

ASAP allows dynamic system
   scalability, allowing the pool membership to change at any time
   without interruption of the service.

Same concern as above.  This is only offered by use of specific services described in services document.  Even with that, there is no guarantee of uninterrupted service.  It is best effort.

Nits:

1.1 Overview

This document defines an architecture, for providinge a highly
   available reliable server function in support of some service. The
   way this is achieved is by forming a pool of servers, each of which
   is capable of supporting the desired service, and providing a name
   service that 

see changes below, misspelled words:

This document defines an architecture, for *providing* a highly
   available reliable server function in support of a service or set of services. 
   This is achieved by forming a pool of servers, each of which
   is capable of supporting the desired service(s), and providing a name
   service that...

2.1 RSerPool Functional Components

Each server pool will be identifiable by a unique name which is
   simply a byte string, called the pool handle. 

see changes below:

Each server pool is identified by a unique name which is
   simply a byte string, called the pool handle. 

   o  A protocol field of the IP header specifying the transport layer
      protocol or protocols.

see changes below:

   o  A protocol field specifying the transport layer
      protocol or protocols.

Please note that the RSerPool architecture supports both IPv4 and
   IPv6 addressing. A PE can also support multiple transport layers.

see changes below:

Note that the RSerPool architecture supports both IPv4 and
   IPv6 addressing. A PE can also support multiple transport protocols.

2.2.1

ENRP employs a client-server
   model with which an name server will respond to the name translation
 service requests from endpoint clients running on the same host or
   running on different hosts.

see changes below:

ENRP employs a client-server
   model in which a name server will respond to the name translation
 service requests from endpoint clients.

2.2.3 PU <-> NS Communication

   The PU <-> NS communication is used for doing name queries. 

see changes below:

   The PU <-> NS communication is used for performing name queries.

2.2.4 PE <-> NS Communication

   The PE <-> NS communication is used for registration and
   deregistration of the PE in one ore more pools and for the

misspelled word:

   The PE <-> NS communication is used for registration and
   deregistration of the PE in one *or* more pools and for the

   o  Multiplexed data and control channel. Both channels are
      transported over one transport connection. This can either be an
      SCTP association, with data and control channel are seperated by
      the PPID, or an TCP connection, with data and control channel
      being handled by a TCP mapping layer.

misspelled word:

   o  Multiplexed data and control channel. Both channels are
      transported over one transport connection. This can either be an
      SCTP association, with data and control channel are *separated* by
      the PPID, or an TCP connection, with data and control channel
      being handled by a TCP mapping layer.

   When a name server boots up a UDP multicast message may be sent out
   for initial detection of other name servers in the operational scope.
   The other name servers send an answer using a unicast UDP message.

Aren't we addressing multicast at a later time?  If so, delete this paragraph.  Otherwise, some nits:

      When a name server initializes a UDP multicast message may be transmitted
   for initial detection of other name servers in the operational scope.
   The other name servers send a response using a unicast UDP message.

2.3.1

communication may not be know by the peer.

   Providing information to which PE the OU should failover can also be
   very important. Consider the scenario given in the following figure.

misspelled words:

communication may not be *known* by the peer.

   Providing information to which PE the *PU* should failover can also be
   very important. Consider the scenario *presented* in the following figure.

Figure 4

Two PE accessing the same PE

Should be:

Two PUs accessing the same PE

2.3.2 Cookies

   Cookies may be sent from the PE to the PU if the PE wants to do this.
   The PU only stores the last received cookie. In  case of a fail over
   it sends this last received cookie to the new PE. 

some changes:

   Cookies may optionally be sent from the PE to the PU.
   The PU only stores the last received cookie. In  case of fail over
   the PU sends this last received cookie to the new PE. 

[Editors note] This section has not been updated. The examples will
   be updated after the architecture has been finalized.

Please delete this.

3.1

After figure 8:

   1.  the Signaling Gateway (SG) receives an incoming signaling message
       to be forwarded to the GWC. SG(X)'s ASAP layer would send an ASAP
       request to its "local" NS to request the list of pool elements
       (PE's) of GWC (using (a)). The key used for this query is the
       pool handle of the GWC. The ASAP layer queues the data to be sent
       in local buffers until the NS responds.

Don't use the word "key" for this as it sounds like some security key.  Use bit string or some other phrase.

some change:

The bit string used for this query is the
       pool handle of the GWC. The ASAP layer queues the data to be sent to the GWC
       in local buffers until the NS responds.

OK, I think that is it for now.

-- maureen 

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