Re: Comments on architecture document -- last call

Hi Maureen,

see my comments below.

Best regards
Michael

On Aug 19, 2003, at 22:38, [email protected] wrote:

> I read this carefully.  Here are my comments.
>
Thank you very much.
> 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.
Accepted.
>
> 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.
The sentence has been deleted.
>
>    In addition, ASAP defines each logical communication destination as 
> a
>    server pool, providing full transparent support for server-pooling
>    and load sharing.
I doubt that this sentence is from me, I also do not understand it...
I replaced it with:

In addition, ASAP provides some mechanisms to support loadsharing 
between
PEs within the same pool and to support the upper layer in case of a 
failover
between PEs becomes necessary.

>
> I don't understand this statement.  What is a logical communication 
> destination?
>
Phil knows this, I guess.
> 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.
Is a server a PE before joining a server pool? That is why I used server
instead of PE. Howeverm, I changed it as you want it.
>
> 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.
You are right. I changed it to

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

>
> 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...
Accepted.
>
> 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.
Accepted.
>
>    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.
Accepted, but also deleted 'or protocols', since the transport protocol
is now unique within a pool.
>
> 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.
Accepted, but also deleted the last sentence.
>

> 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.
>
Accepted.
> 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.
Accepted.
>
> 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
>
Accepted.
>
>    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.
>
Accepted.
>
>    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.
We do not address this later in this doc.
> 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.
>
Accepted.
> 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.
>
Accepted.
> Figure 4
>
> Two PE accessing the same PE
>
> Should be:
>
> Two PUs accessing the same PE
>
Accepted.
> 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.
>
Accepted.
> [Editors note] This section has not been updated. The examples will
>    be updated after the architecture has been finalized.
>
> Please delete this.
>
Accepted.
> 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.
>
I just deleted the sentence 'The key used for this query is the pool 
handle of the GWC.'
> 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.
I accepted the change to the second sentence.
>
>
> OK, I think that is it for now.
>
> -- maureen 
>
>
> _______________________________________________
> rserpool mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rserpool
>