Subject: [Rserpool] SLP conference call minutes from 9/13

From: "Stillman Maureen (NVO-NIC/Ithaca)" <[email-masked]>
Date: Fri, 21 Sep 2001 08:44:03 -0500

As always, send any comments to the list.

-- maureen

Minutes of the 9/13/2001 teleconference 11AM EST USA

Attending:
Qiaobing Xie
Maureen Stillman
Ram Gopal
Senthil Sengodan
Xingang Guo
Michael Tuexen
Lyndon Ong
Paul Lin
Linda Cline
Erik Guttman
Chris Ross

The agenda of this call was to discuss the relationship between SLP
and Rserpool.  The working group would like to make progress in 
determining the technical relationship between the two.

DA = SLP Directory Agent
SA = SLP Server Agent
UA = SLP user agent
  
Qiaobing had sent a number of issues to the list.  We began a discussion
of these issues at this telecon.

We discussed what we wanted to achieve in our teleconference.  

Erik: The goal is to step back and answer the questions:
1) What do we want from a namespace?
2) How do we achieve these goals?

Qiaobing Issue #1: 
In SLP, the presence of DAs is optional and UAs can direct get 
service location information from SAs. This seems not good for Rserpool 
since if we want to support this DA-less operation mode, The SAs in the 
target pool will have to implement all name service functions in 
themselves... this could mean a lot of complications. Therefore, for 
Rserpool SLP deployment, DA support should be made mandatory. 

Consensus reached: For now, we should assume that a DA is required and
not optional.
This will allow us to focus the debate on the remaining issues.  

Discussion: 

Erik: We need to know what are the name server functions.

Qiaobing: We need name server functions to support L5 and L4.  Whatever
it takes to make that happen.

1) High performance clustering of servers.
2) end space service
3) determine what we should build into it

Clustering implies more functionality to manage. 

Erik: A SLP service is modeled as a set of instances.  They are at
different locations, with different service types and different service
attributes. 

Qiaobing: Represent servers as a single entity.

Erik: In SLP, servers are instances of a class.  

Qiaobing: Client only needs to know the logical handle of a group of
entities. 

Erik: The default is to send abstract descriptions and get back a handle
or get back URLs.  An intermediate step could be to give a server
description that is higher level and get back a session layer pool
handle.

Qiaobing:  I don't want to get into the service area.  In SLP the
response to a query can come back from a DA or an SA.  Some of the DA
functionality is also handled by the SA.

Erik: The client just wants a reply reliably and quickly, it doesn't
matter where the reply is from.

Qiaobing: ENRP has a centralized name space.  User queries this name
space and gets a response.  It is a different model.  There is no DA
functionality in the servers or PEs.

Erik: SLP has the same model when you have a DA.  We need to think
functionally.

What we need at higher layers is to provide a naming function.  The
lower layers can be solved peer to peer.  The degenerate case is where
the DA fails.  Then the system can function (using SAs) but with less
efficiency.

Qiaobing:  In the mode where these is no DA, the burden of the namespace
discovery is on the user side.

Erik: We don't want to throw the baby out with the bathwater.  What we
get with this functionality in SAs is the ability in a local network to
continue to operate if all DAs fail.

Ram: Are the SA queries always multicast?

Erik: There are three transport protocols used:
TCP
Multicast convergence algorithm using UDP
Unicast UDP

SA can receive either unicast or multicast.  If there are large URLs
then they must use TCP.  UAs can talk directly to SAs.

Consensus reached: For now, we should assume that a DA is required and
not optional.  This will allow us to focus the debate on the remaining
issues. 

Qiaobing #2 issue: 
Create and define a Rserpool scope string.  We need to assign this to
Reserpool PU, PE and DAs.  This will separate Rserpool from all other
SLP useage.

Qiaobing: SLP deals with applicaiton layer entities.  Rserpool deals
with session layer.

Erik: Notion of scope in SLP allows you to configure it for an
administrative group, organization, geographic, etc.  User only sees
what they should see.  Scope is an SLP layer multiplexer.  Typically SLP
is used in a single administrative domain.  However several companies
can share scope.  Several companies can share a global multicast
address.

SLP = discovery and name rsolution at any layer above the transport
layer.

Ram: We can't rely on multicast routing being present for Rserpool.

Erik: Yes, we can't multicast query.  The solution is to put SLP record
in the DNS SRV. That will allow you to get to yourcompany.com and to get
to the DA.

Ram: Suppose C1 and C2 have similar services.  The DNS will find DAs.
DNS service model = each qualified domain is distinct.  Each domain will
have to have their own DA.

Erik: C1 has a DA that covers C1 and C2.  Whois servers are the owners
of domain name. Use SRV records.

Q: We need persistence of the pool handle.  In some cases we need to go
back to the same server again.  SLP doesn't support this.

ENRP takes a tuple and returns information.  It can be specific or
general.  URL used by SLP functions on the applicaitons level.

Erik: Format should be URI.  The format is: 
data: put anything here URI used because the left says what the
semantics are of the data on the right.

Erik: We need a strategy.  We need to get to the core issues.

1) Idetify naming functions that we need
2) How do we support them?  
If we determine that SLP is a candidate, then we will investigate
further.
Otherwise, it is not a candidate and we continue without it.

Qiaobing:  It is not purely a question of functionality but is also a
question of performance.

Maureen:  I think that reliablity is the most important.

Qiaobing: I meant that also when I said performance. 

Erik's email on 5 functions of the name server:

Let's make it clear that there are 5 distinct functions:

   1) Bootstrapping (finding servers to resolve names and register PEs)
   2) Resolve service description to pool handle (this is not currently
      discussed in any rserpool doc)
   3) Resolve pool handle to pool element handles (actual locations)
      Allow PUs to get this information efficiently. Keep it up to date.
      Allow PUs to find out changing attributes and availability of PEs.
   4) Register availability of PEs and their current status.
      Deregister PEs when not available.
   5) Maintain distributed state of PE location, load & availability
      between name servers over time.

Qiaobing: For #1 performance and reliability are the key requirements.
These are not just fuctional requirements.

Erik: All but #2 are present in ENRP.

Qiaobing: Yes, and we can do these reliably.

Erik:  It seems that SLP can handle 1, 3 and 4.  The question is whether
or not SLP fulfills #5.

Qiaobing: #2 is not in the scope of Rserpool.

Erik: SLP with mesh SLP: can it support distribution of name state in an
acceptable way?

Qiaobing: ENRP does this reliably.

Qiaobing: With regard to #3, how good or how reliable?

Erik: We need an analysis of SLP with mesh SLP.  What kind of delay is
introduced using mesh SLP?

Erik:  I propose that Qiaobing and myself will work on further on the
SLP issues offline.  We need to decide if SLP can fulfill the
requirements or not.  If so, we need to determine any changes to SLP are
needed.  If it will not fulfill Rserpool requirements, then not.

Discussion: What version of SLP should we investigate?
  
Maureen: SLP v2 does not fulfill the requirements of Rserpool.  We must 
consider mesh SLP along with SLP v2.

Consensus: Erik and Qiaobing will investigate SLP v2 with mesh SLP and
report back to the group.  In terms of the requirements, there was
agreement to work with the current requirements document.

Mobile: (607)227-2933

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