Subject: Re: service discovery input

From: Erik Guttman <[email-masked]>
Date: Thu, 6 Jan 2000 08:37:27 +0100 (MET)

Brent,

I point out in my comments below where I think your definitions
are perhaps to weighty.  Service discovery, as we are discussing
it, needs to be disencumbered from discussions of how it is
implemented (in software/hardware), and where it is implemented
(in devives).  That is why I prefer the terminology of 'processes'
to describe the 'discovering' and 'advertising' agents.

Many of the terms you bring up were lacking in my list and I
think they are great additions (registry update mechanism,
registry cleanup, discovery mechanism, client lookup mechanism,
client access to service, client use of services).  I prefer my
own definitions for the following terms (client agent, service
agent, service, registry) for reasons I give below.

> >   a) What are the major components of service discovery?

> 1. Client agent: The client agent is a software component that runs 
> in a device and searches the network to find services needed by 
> applications running in the device. Note that services themselves 
> can be clients of other services.

I prefer to characterize the client as a process than as software.
The definition of a 'client' should require a definition of a 'device.'

> 2. Service agent: For devices that provide services to other 
> devices, the service agent is a software component that advertises
> the services provided by the device. In the case where a service 
> provider implementation does not require hardware, a service agent 
> can be based entirely in software.

It is not necessary to define a device to define a service, though
a service may be contacted at an address, with a protocol.  The
discussion of hardware and software doesn't add clarity to the 
definition.

> 3. Registry: In order to provide efficiency and scalability, some 
> of these protocols provide for a (perhaps optional) registry where 
> information about available services is maintained. Typically a
> registry contains an entry for each service advertised by a
> service provider. The registry can be centralized or decentralized 
> (distributed).

The registry doesn't only contain information about services, it has
to contain all the information which the service agents advertise.
This includes at least the location and type of the service, but
it can include more - such as service attributes, authentication
information, etc.

I know of no distributed service registries.  It is possible that
new registries can be elected (such as the browser election scheme
used in MS networking) but this is still a centralized scheme.  It
is precisely the centralization which adds scalability.

> 5. Registry cleanup: This topic addresses how obsolete or 
> incorrect information is purged from the registry.

The reason for a registry clean up is that we don't want stale
information hanging around.  Service discovery registries are
different than directories in that there are timeliness guarantees
we want to make about information in the service registries.

> 6. Discovery mechanism: The discovery mechanism is that part of a
> service discovery protocol that specifies how a client locates 
> the service discovery infrastructure such as a registry.

Maybe this should be called discovery protocol autoconfiguration.
The idea is that there is some mechanism used by the service 
discovery protocol so as to automatically allow scalable behavior
in the presense of a service registry.

> 7. Client lookup mechanism: The client lookup mechanism defines
> how a client queries the registry (if there is one) to locate a
> service it needs, and how it locates the service in the absence 
> of a registry.

The question is how does this differ from nclient lookup from service
agents (and in protocols which define an optional registry it does 
differ if only slightly - such as SLP and MDNS vs DNS).  These 
differences are mainly in the transport of the query and the reply
not the message contents per se.

> 8. Client access to service: This topic addresses how a client, 
> once it has located the service that it needs, negotiates access 
> to the service, including "quality of service" issues and security 
> issues.

The key statement here is 'once it has located the service that it
needs.'  A client which finds all databases on the network doesn't 
necessarily have access to any of them, they don't necessarily 
support the access protocols the client has nor do these databases
necessarily contain the data the client is looking for.	 In short,
unless the client finds the set of services which it needs, it will
have to do a negociation phase with the service where the client
determines - as part of initially attempting to access it - whether
the service *is* what the client needs.  

This is what I am attempting to get at in the notion of whether
service discovery is conclusive.  'Client access to service' is
made much simpler if the service discovery allows for rich querying
semantics so that the client will only discover services which it
in all likelihood does not need to do any feature negociation with.

> 9. Client use of services: Once a client has located a service, 
> and has successfully negotiated access to the service, it must
> determine (and perhaps acquire) the protocols to actually interact
> with the service (for instance: IPP, LPR, HTTP, FTP, Java RMI).

Here I completely disagree - the client has to have the protocol
required to communicate with the service a priori.  It may be, in
the case of RMI or CORBA that the client will download an interface
to a remote service which it acquires only after discovering the
service.  But the client must in any case have code which can drive
that interface (at the API level).  In that sense it is true that the
client does not need to support the wire protocol for client server
communication in advance, but it *does* need to support RMI or corba
to enable this.

In any case, how clients use services is out of the scope of the 
ZEROCONF working group.

> >   b) Definition of a service
>
> I believe that this should tend toward a very generic definition.  
> Again I'll steal shamelessly from prior art.  The definition below 
> is from the Bluetooth (TM) Service Discovery Protocol Specification:
>
> "A service is any entity that can provide information, perform an 
> action, or control a resource on behalf of another entity. A service 
> may be implemented as software, hardware, or a combination of 
> hardware and software."

We are only interested in networked services in the ZEROCONF working
group.  This precludes 911 (provides information), pizza parlors (which
provide services) and the electric utility (which controls resources).

The services we are concerned with have an IP address and port number, 
and a specific protocol which clients use to communicate with them.
They may also have additional details which clients need to know before
they are ready to communicate with them (configuration information, for
example).

> >   c) Is service discover[y] conclusive?
> 
> I'm not exactly positive what is meant here.  It should at least
> be conclusive from the client's point of view that a service exists 
> which matches the client's query or not.  The trick is in specifying 
> what might go into that query.

I'll take this up in another message.

> >   e) What is the goal of service discovery?

> Self-configuration.  Devices should be able to be installed in a network
> and "just work".  Part of this includes those devices being able to specify
> what services they offer to other participants in the network and to
> discover what other services are available on the network, with "zero
> configuration".

I don't like the device focus.  Clients running in the network should
just work.  Nothing should require any configuration, but if configuration
is available, it can be used to make service discovery more scalable,
secure and 'personalized' (only finding services which I care about,
am allowed to use, etc.)

> >   g) Bootstrapping protocol or not?
> >   h) How does a service discovery protocol support both simple and
> >     complex devices in a ZeroConfig network? ]

> What exactly are we trying to get at here?

I am also not sure what is being asked here.

Erik

---

From: [email-masked]
Date: Thu, 6 Jan 2000 10:39:55 -0500

Erik,

My responses included in-line below with "==>" tags.

Regards,
Brent
B. A. Miller RTP, NC
(919) 543-6959 TIE 441
FAX (919) 254-5739
Internet: [email-masked]

---------------------- Forwarded by Brent Miller/Raleigh/IBM on 01/06/2000
09:03 AM ---------------------------

Erik Guttman <[email-masked]>@merit.edu on 01/06/2000
02:37:27 AM

Please respond to Erik Guttman <[email-masked]>

Sent by:  [email-masked]

To:   Brent Miller/Raleigh/IBM@IBMUS
cc:   [email-masked], [email-masked]
Subject:  Re: service discovery input

Brent,

==> In ZEROCONF context, your suggestion is appropriate and I
agree with the use of "processes".

==> These terms/definitions resulted from dissecting the general
problem and general solutions, so I'm glad you think they are
relevant.  I think we're mostly but not entirely in agreement
on the definitions for the terms, addressed individually below.

==> Agreed.

==> While a complete solution requires dealing with both devices
and services, I agree that they should be addressed separately and
thus again using the idea of a "process" here makes sense.

==> Well, these examples are exactly what I meant by "information
about services".  The registry will indeed contain at least the
service advertisement *information about the service*, and it may
contain attributes or access control *information about the service*.
I think we're saying the same thing here.  Perhaps the definition
needs to be made more clear using wording such as you suggest.

==> "Distributed" may be a poor term here.  The point which is
attempting to be made is that a service provider may have its own
"registry" of services and thus need not rely on a centralized,
third-party registry.  Thus the client can contact the service
provider directly to learn about services; the service provider
consults its own "registry" to respond to the client (like in
Bluetooth or in SLP without DAs), as opposed to the client
contacting a registry to find out about a service and then
contacting the service provider based upon information obtained
from the registry.  But I agree that the idea behind a registry
as is germane here is that it is centralized for scalability,
although it might be "distributed" in a hierarchical decomposition
a la DNS, but that is just talking about the degree and placement
of centralization.  So having said all that, I'll accept a
definition that says that a "registry" is "centralized", although
service discovery can still be accomplished when the information
about services is decentralized, meaning that the service
providers maintain this information on their own rather than in
a centralized registry, but I think the point is that we shouldn't
call that collection of information a "registry".  Right?
How's that for a run-on sentence?  ;-{)>

==> Agreed, except perhaps on the minor point of "guarantees".
There is temporal information associated with a service that
needs to be reflected in the registry and thus requires a
cleanup process; this may or may not go so far as a timeliness
guarantee.

==> Agreed.

==> Agreed that the difference is subtle, with the idea being that
"discovery" lets me find out about the presence and location of
a "database" (term used loosely) of information about services,
and "lookup" specifies how I query that "database" to learn about
those services.  And this dissection indeed is relevant primarily
(exclusively?) when the concept of an optional registry exists.

==> I agree that it is completely reasonable and probably preferred
to have rich querying that enables the client to discover just
those services that are in fact "what it really needs", and in doing
so it is reasonable to include some "access method" attributes or
filters in the querying semantics (so that I can indeed find just
the public, available, nearby, free color duplex Postscript printers
and not just all of the printers that some registry knows about).
However, I think it is still useful to keep the "access" component
separate.  I still have to discover a service and get access to it;
an optimization (and a good one) is to just discover the services
that I can (or am likely to be able to) get access to.  Also
consider a scenario where a service is accessible to a client that
provides some sort of credentials or asset (like a key or a credit
card number) -- in this case it may indeed make more sense to
discover the service and then negotiate access to it.  I agree
that things like features ought not to be negotiated, but rather
filtered in the query response, but it still seems to me that there
are some "orthogonal" characteristics of a service that still might
be negotiated separately after discovery.

==> Well apparently we may be in complete disagreement, but as
you correctly point out this is outside the scope of ZEROCONF and
if we want to debate this further we should do so outside of
the ZEROCONF forum [but I can't resist saying that we're probably
not really in total disagreement, and you've (I think) hit upon
the main idea behind this item, which is that the discovery
protocol can be entirely independent of the service access
protocol.  It should be possible for me to use *only* the discovery
protocol to *find* a service and learn that in order to actually
make use of that service I need to have the MagicGuttman protocol,
which I may be able to obtain (and again, the discovery protocol
might tell me how and where to obtain it) if I don't already have it.
Agreed that I need to know how to drive the MagicGuttman protocol
once I do obtain it, but I don't necessarily need that protocol
a priori (nor even a priori knowledge that the service uses
that protocol).   I see this as similar to item #8 above --
it is perfectly reasonable to only find services that use
protocols that I know about and have (or have access to), but
I still think it is useful to keep the concept of "service use"
separate from discovery in the general case, since I may in fact
wish to use the discovery protocol to determine the service usage
protocol, if the solution provides a way for me to acquire and
drive that service usage protocol.  It all depends on how one
approaches the problem.  And I do agree that the client needs
*some* protocol a priori in order to make this case work; it
just isn't *necessarily* the protocol used to interact with the
service itself.  But then we've agreed that this is outside the
ZEROCONF scope, so why am I rattling on so?  ;-{)>  ].

==> Hmm, I guess it depends upon how one defines a "networked service".
By your definition below, which I agree is appropriate for ZEROCONF,
the examples above are indeed excluded.  But one might argue that
911 and electrical utilities are indeed networked services (just
different networks than IP networks).  But I'll agree that they're
not services of interest for ZEROCONF.  But in the most general
sense, I do believe that these are services, which could in fact
be discovered under appropriate assumptions and conditions.  But
I won't press this point in the ZEROCONF scope.

==> See above.  Agreed that these are the services of interest for
ZEROCONF.  Toward clarification, can we assume that the following are
ZEROCONF services if they meet the above definition?
- a shopping mall kiosk information service that I discover with my
PDA when I walk into the mall
- a network access point point whose service is that it provides
me access to "the network" (and thus is the service that lets me
discover the "networked services")

==> Good.

==> O.K., I once again agree that keeping devices and services separate
architecturally is the correct approach.  I'll reword to:
  "Self-configuration.  Services should be able to be installed
  in a network and "just work".  Part of this includes service
  providers being able to specify what services they offer to
  other participants in the network and clients being able to
  discover what other services are available on the network,
  with 'zero configuration'."

==> Myron?

Erik