Subject: [Rserpool] A variety of comments from a lost soul

From: "Brad Stone" <[email-masked]>
Date: Wed, 21 Mar 2001 19:59:06 -0800

Here is my feedback on each of the documents:

========================================
Requirements document:
This would probably be a good place to put all the terminology instead of spreading
it inconsistently across the drafts.

There seems to be value in allowing ASAP/ENRP for service discovery, followed by
client/server communication over a separate protocol (e.g. TCP). This would allow
for some capabiliites such as load balancing without other such as real-time failover.
The document doesn't seem to allow for this - instead implying that a proxy is needed.
[and yet the ASAP document does seem to allow for it...]

The document indicates that multicast should not be relied on. However ENRP seems 
to rely on it.

Regarding server selection: 
"ASAP layer ... using the server selection algorithm in the reply message from the
ENRP server".
"The ENRP servers should be extensible using a plug-in architecture."
I can't figure out where you expect the actual selection to be done.

Security:
"The ENRP Client has to use authentication before registration, deregistration."
Do you mean the ASAP endpoint?
========================================

========================================
ASAP Draft:
If an ASAP endpoint wants to continue supporting existing connections, but wants to
temporarily stop new connections, can it DEREGISTER? Depending on the policy, there
may not be an UPDATE_POLICY_VALUE message that would achieve the same effect. The
document indicates that DEREGISTER should be used (only?) as part of a graceful shutdown.

========================================

========================================

ENRP draft:

In Abstract:
from: "Endpoint Name Resolution Part (ENRP)"
to: Endpoint Name Resolution Protocol (ENRP)
rationale: just a typo I think.

from: "ENRP defines the fault tolerant name translation service."
to:   "...the highly available name translation service."
rationale: Fault tolerance implies additional levels of sophistication.

In Introduction:
from: references to "fully distributed"
to: "distributed"
rationale: Not sure what you are implying by saying fully distributed. The ENRP role
is certainly distributed, but fully distributed would imply (to me) that all pool elements
provide the ENRP role, which I don't think is the intent.

Motivation:
question: Why is the motivation for developing *ASAP* being explained in the ENRP doc?

Section 1.1.1:
from: desinged, availablitity
to: designed, availability
rationale: typos

from: Remove (1)
to: After describing the other limitations (2-5), provide an unnumbered paragraph similar to
the following:
   It is recognized that CORBA has recently developed high availability features, but due to
the above limitations that would still exist, CORBA was not considered a viable solution.
rationale: (1) I find the references to CORBA's new fault tolerance mechanisms as 'immature'
and 'unproven' to be odd when used as a justification for a completely new protocol.

Section 1.1.2:
from: 2nd paragraph and last paragraph
to: move to 1.1.3 and generalize to say that ENRP (ASAP?) may be extended in the future
to provide interoperability with other name services.
rationale: Paragraphs do not describe DNS or its limitations.

Section 1.2:
from: relam, entitiy, peroidically
rationale: typos

Section 1.3:
from: "...name to in name space."
to: "name."
rationale: not sure what else you are trying to say.

from: "When sending a message, the sender addresses the receiver endpoint by its name..."
question: or "by its endpoint handle"?

from: "...they will be treated as a receiver pool..."
to: "...they will be treated as a named group..."
rationale: You seem to be trying to get rid of references to 'pool'. Don't know why....
Or does 'named group' mean something else?

from: "be dynamically add to"  "and and"
to: "be dynamically added to"  "and"

Section 1.4:
from: "the name space in a high availablitity manner."
to: "the name space in a highly available manner."

Section 1.5:
There is no explanation for why you preclude hierarchical namespaces. 

You mention the use of DNS, followed by the use of ENRP. Is this what you meant by
interoperability? Although I don't want to put ENRP capabilities into DNS, I was
hoping that we could put some DNS capabilities into ENRP. Specifically, I was 
hoping for the following:
   The ENRP server provides support for ENRP requests as well as delegation support 
   (I think that's the right term) for DNS requests. The ENRP server would be capable
   of receiving both types of requests. A DNS request to a DNS name would just be
   delegated to a DNS server authoritative for that zone. A DNS request to an ENRP
   pool name would get a static answer in which the ENRP could determine the policy for
   ordering the list in the response, setting TTL, etc. This would allow for DNS
   applications to take advantage of ENRP-based services with degraded capabilities.
   It would also motivate service providers to use ENRP since they would be reachable
   by all (ENRP and non-ENRP) clients.

   The ENRP server could also translate ENRP requests for DNS names to/from DNS 
   and then delegate, but I don't see how this would be valuable, unless it
   could completely hide the issue of DNS vs. ENRP names from the client. [currently
   client has to know whether pool is DNS-based or ENRP-based, right?]

Section 2.1.1.3:
from: "If the name exits"
to: "If the name exists"

Is the policy applied to the members in the NAME_INFORMATION message (i.e. is this the
load balanced list?). The requirements indicate this would be done in the ASAP layer,
but I'm not sure why it wouldn't be done by ENRP as it builds the list. For scalability
reasons it may make sense to return only the 'top10' or whatever to reduce buffer
space on the receiver. The requirements doc indicates that for large pools it should
be possible to return only a subset of all the pool members. Return to whom? PU? ASAP layer?

Section 2.1.1.4.1:
If an ASAP endpoint belongs to a named group, and is then added again to the group
with new attributes, shouldn't the new attributes be updated in the peer's copy? Why
should this be different than the update message described in 2.1.1.4.4?

Regarding the last paragraph, it may not be good for peer to unilaterally take
ownership for a newly registering endpoint. If this ENRP peer is flaky (which may
be why endpoint wasn't talking to it anyway) it may create problems. For example,
if an ENRP server had a bug and wasn't resetting endpoint-report-failures, there
would be no way for that endpoint to 'escape' and use another ENRP server. Endpoint
would register, the update would be broadcast, the local ENRP would claim the endpoint,
then shut it down. Maybe it would be better to ask current owner. 

Reference to 2.1.1.12 is wrong; should be 2.1.1.4.5?

Section 2.1.1.4.6:
When does the endpoint-report-failures counter get reset? Is it persisted across ENRP
server restarts? 

Probably shouldn't be reset on a successful keepalive, since home ENRP is probably
on same host. Also can't assume that other endpoints will continue to report failures.

How does an endpoint know he was removed from a pool?

Is the MAX value on a per pool basis? It seems that if you had a large pool with
intra-pool communication a minor blip would cause a bunch ('bunch' > MAX) of peers
to each report a single failure which cause the endpoint to be removed.

Section 2.1.1.5:
Changing a policy value affects everyone in the pool, so you might as well allow an
UPDATE_POLICY_VALUE message to update an arbitrary endpoint's policy value (not just
the sender's). There would also be value in an arbitrary user changing the value,
as long as it could be done securely. [I haven't found the security section yet]

Is it expected that an endpoint would know the policy being used? It seems more likely
that this would be controlled through a 3rd party anyway.

Section 2.1.1.8:
Are peers listed in a PEER_LIST_RESPONSE assumed to be active? Or is the state also
included?

Section 2.1.1.9:
Why should a local ENRP server be assumed? At a minimum an endpoint should be able to 
persist the last known home ENRP server address, and try that on startup. The local
ENRP will usurp it anyway.

Section 2.1.2.4:
Is there a way for a peer (C) to prevent a peer (A) from performing a takeover of
a peer (B)? The case I'm concerned about is one where everybody in the pool can talk
to everybody else, except A can't talk to B (maybe a routing problem). It would be
nice to tell A to shut up and leave B alone.

Section 2.1.2.5:
from: "and a caretaker other than itself exists for that node."
to:   "and a caretaker other than itself exists for that node and its state is active."
rationale: If the caretaker is dead, it won't be able to register the endpoint, which is
probably why the registration is being sent out.

Question: named group vs. server pool vs. receiver pool
Are these all the same thing?

Q: How does ASAP endpoint know its ENRP server address at startup (so that it can register)?
It assumes local host and that ENRP server is at a well-known address? 
The registration message is not included in the document.
Protocol should allow for a non-local server to be used at startup.

Q: With ENRP, can I get a list of ALL members of pool (vs. ones that are up)?
What's the NAME_INFORMATION message look like?
Is this is the load balanced list?

Q: ENRP Server communication - requires multicast? What type of multicast? Does SCTP
support multicast? Is it reliable?

Q: How do you prevent someone from joining your pool?
Can't find anything that prevents someone from joining pool, then making an
UPDATE_POLICY_VALUE message to ask for all the requests.

Q: How do you prevent someone from hijacking your pool? If pool members come and go,
thief waits for membership to temporarily drop to 0, then hijacks it. 

========================================