Re: [dnssd] Generalized service discovery requirements/goals

[Tim Chown <[e-mail]>]

Hi,

On 23 Jul 2014, at 16:42, Dave Thaler <[e-mail]> wrote:

> In offline email that Kerry Lynn and I exchanged, I sent what I wrote up some
> time ago about what I believe applications want from service discovery in
> general, based on experience and customer feedback over the past two
> decades, to provide additional context/input for the dnssd requirements
> discussion.  He then recommended I also send it to the list, so here it is.
> If folks think it would be useful in I-D format, I could do that.

Thanks for this Dave, it’s a useful perspective on the work in hand.  

Some initial comments below.
> 1      Introduction
> 
> “Service Discovery” encompasses discovery of various types of services, such as  devices, servers, application instances, etc.   All of these have some common aspects, including:
> 1)      Three levels of identifiers:
> 
> a.       A “service” (e.g.., a type of device, server, or application) to discover instances of.
> 
> b.      A particular “instance” of a service running on a specific network node, potentially reachable via multiple endpoints.  There can be multiple instances per service.
> 
> c.       A particular endpoint (e.g., IP address + port) at which an instance can be reached.  There might be multiple endpoints (e.g., IPv4 and IPv6) per instance.
> 

Agreed, and useful to differentiate.
> 2)      The following are some typical application operations:
> 
> a.       Enumerate all instances with minimal delay, and be immediately notified of changes.
> 
> b.      Get additional properties of a given instance (e.g., whether a printer supports color).
> 
> c.       Reconnect to a given instance, even if the endpoint has changed.
> 
The existing requirements draft doesn’t talk about specifics of what may be discovered, rather the characteristics of how an extended multi-link protocol should operate. But from the application perspective, these are very valid points.
> 3)      Multiple zones of interest (sometimes called “scopes”) within which to do discovery, such as: Local subnet, Physical proximity, Services the user has used before, Organization-specific, etc.   
> 
Or “my home” (whether I’m in it or not), etc...
> 4)      The following characteristics are important in how results are ordered/used.   The relative order of importance of the characteristics is often a choice made by a user or application developer.
> 
> a.       Features: an instance that supports a particular feature (e.g., color) may be more useful than one that does not.
> 
> b.      Live-ness: a currently reachable instance is typically more useful than an unreachable one.
> 
> c.       Proximity: an instance nearby is typically more useful than one farther away.
> 

So a couple of things here.

One is following the ‘stale information does not persist’ principle, unreachable information should not be retained.

Another is that we should probably distinguish discoverable (that the service is there) from reachable (e.g. it’s not firewalled from where I am) from usable (I can access/authenticate and use). 
> 2      Background
> 
> There are a number of key issues today that need to be addressed.
> Guest access: An increasingly common scenario is that of guest access, both within homes as well as within business environments.   This makes the concept of zones of interest more complicated.   Guests might or might not be permitted to discover and access a home printer for example, so might require a separate zone of interest for discovery.   Often guest access is implemented as a separate local subnet, which leads to the next problem.
In the homenet model, there are ‘realms’ and borders, and there’s an assumption of default policies being applied at borders, which may be overridden.

But there may be a ‘zone of interest’ of ‘devices in my home that a guest can use’, wherever they happen to be topologically.
> Multiple subnets: Many service discovery mechanisms today are designed for “local subnet” being the zone of interest.   However local subnet is not a user-visible concept and is becoming more and more at odds (e.g., due to guest access, mobile broadband, etc.) with typical consumer scenarios such as “within my house”.   That is, users care more about tangible Physical Proximity than a nebulous “local subnet” they don’t understand.   This makes link-scoped multicast solutions a poor match for such scenarios.
Indeed. 
> Efficient filtering: In many scenarios a client has a set of specific properties with which it wants to constrain the answers, such as only discovering color printers that can print double-sided.   This can be implemented by using a simple query to enumerate all service instances, getting the properties of them, and then filtering the results, OR by a complex query to enumerate all service instances that fit the criteria.   Although the latter would be more efficient, the complexity proved to be a problem and as a result the widely deployed protocols all use fairly simple queries.   The filtering is thus typically done by an API layer on top of the protocol, allowing applications to submit complex queries while using simple protocol queries underneath.
I believe this issue is the subject of tomorrow’s TXT discussion, see http://tools.ietf.org/html/draft-aggarwal-dnssd-optimize-query-00.
> Power-efficiency: Power conservation is becoming increasingly important.   With this trend comes the need to support discovery of services that are in a low-power state.   This requires either offload support in the network adapters at the service instances (as is available in some cases for mDNS for example), or a directory in another server.
> Live-ness detection: Determining live-ness of a service instance can be an issue when using a directory in another server, or when the zone of interest is “Services the user has used before” for instance.   Increasingly there are cases where it is expensive to determine whether a device is online or offline (e.g., if it went into a low power mode).  Furthermore, live-ness of a service is different from live-ness of the device hosting the service.   For example, the printer may be reachable but if it is jammed, it is less live than one in the ready-to-print state.  Another aspect of liveness is notification of changes when a device becomes online or offline while a client is in a user experience showing the available instances from which to choose.
Agreed, and your pointer to DNS LLQ at IETF89 was very useful in this regard.
> Managed environments: Managed environments use various types of directories (e.g., DNS servers, LDAP servers, etc.) for service discovery. Updating such directories requires certain privileges however, which may not be available to all services.  For example, in many networks, DNS updates are only permitted from DHCP servers.  Such permission constraints present obstacles to discovering unmanaged device and application instances.
> 3      Requirements
> 
> #
> Requirement
> 1
> An app can enumerate available zones of interest
> 2
> An app can discover instances of a given service within a specified zone of interest
> 3
> An app can determine whether an enumerated service instance is online
> 4
> An app can be notified whenever a service instance is added or removed
> 5
> An app can advertise a service instance within a specified zone of interest
> 6
> Advertised endpoints match the endpoints actually being listened on
> 7
> Support zones of interest that may be larger than single subnet but smaller than “everything”
> 8
> Identify a service instance in a way that is not tied to any endpoint so that if it is discovered multiple times with different endpoints (such as in two zones of interest at the same time), the app can tell they are the same service instance
> 9
> Enumeration must include service instances that could be in a low power state
> 10
> Discovery should require zero configuration by a human on an unmanaged device
> 11
> Support zero configuration for advertisement on unmanaged networks
So it would be interesting to map these to REQs in the existing requirements text - are there any explicit and important gaps to catch?
> The following are NOT requirements.
> ·         It is not required that one be able to advertise within any arbitrary zone of interest an instance that has no trust relationship. 
> 
> ·         It is not required that enumeration only return a set of online instances.  It is acceptable to return some offline instances as long as there is a way to determine whether an enumerated instance is online.  This is consistent with the fact that an instance may change its online/offline state at any time, such as immediately after being enumerated.
> 

The existing requirements draft is more focused on the networking aspects of scalability. So, given this is a nice initial stab at an application perspective on SSD, I personally think it would be worth capturing it in an I-D (whether we then move to publish it or not) and pushing it towards application area people for comment.

Tim