Subject: [dnssd] Generalized service discovery requirements/goals

From: Dave Thaler <[email-masked]>
Date: Wed, 23 Jul 2014 15:42:59 +0000

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.

-Dave
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.

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.

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.

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.

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.
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.
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.
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.
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

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.

---

From: Tim Chown <[email-masked]>
Date: Wed, 23 Jul 2014 19:45:32 +0100

Hi,

> 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.
> 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.
> 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...
> 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). 
> 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.   G…
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 m…
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.…
I believe this issue is the subject of tomorrow’s TXT discussion, see http://tools.ietf.org/html/draft-aggarwal-dnssd-optimize-query-00.
> 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 in…
Agreed, and your pointer to DNS LLQ at IETF89 was very useful in this regard.
> 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?
> ·         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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Jul 2014 15:47:15 -0400

> a.  A "service" (e.g.., a type of device, server, or application) to
    > discover instances of.

So, "printer"?

    > 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.

So, does this mean that the printer has multiple trays with different colours
of paper, or rather that maybe it is really a print server that has multiple
queues for different physical devices?

    > 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.

So the print server is attached to both the wired and wireless networks with
different addresses?

    > b.  Live-ness: a currently reachable instance is typically more useful

Of course, you might also want to find the one that is less reachable,
because maybe that's the one you want to fix?

    > simple protocol queries underneath.  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.

Is finding a printer that has been recently used, and is therefore still warm
and powered on interesting as well?  So, it's not just that you want to
discover it even if it is off, but you also want to know when it was last
discovered?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Dave Thaler <[email-masked]>
Date: Wed, 23 Jul 2014 20:01:48 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
> Richardson
> Sent: Wednesday, July 23, 2014 3:47 PM
> To: Dave Thaler
> Cc: [email-masked]
> Subject: Re: [dnssd] Generalized service discovery requirements/goals
> 
> 

Yes.

> queues for different physical devices?

More likely the latter, but there may be more than one way to expose
"printers" so I'm trying to keep this more abstract.  But for clarity, sure
a specific printer or print server queue is usually a service instance.   It
may have multiple endpoints (e.g. IPv4 vs IPv6).

> So the print server is attached to both the wired and wireless networks with

Right.   Or just on one dual-stack network, thus having both IPv4 and IPv6
endpoints.

> Of course, you might also want to find the one that is less reachable, because
> maybe that's the one you want to fix?

Sure.  The 'typically' just refers to the common case.  Point is there's
no one-size-fits-all ordering.

> discover it even if it is off, but you also want to know when it was last

I haven't heard of that desire before, but it's possible there may be
desires for that sort of thing too.  To generalize a bit into a possibly
more common case, "devices that are already in a higher powered
state might be more desirable than devices that are in a low power
state".   That would usually come due to either of two desires:
a) A policy to minimize power costs across the service, or
b) A desire to talk to the device as soon as possible, where there may
    be latency added if the device first has to come back into a high
    powered state.

-Dave

---

From: Michael Sweet <[email-masked]>
Date: Wed, 23 Jul 2014 16:57:17 -0400

Michael,

> queues for different physical devices?

In the context of Bonjour, LDAP, and SLP, the instance represents the printer.  For IPP we advertise the primary/default print service, and have supplemental information pointing to any fax or scan services on the same printer.  Things like the embedded web interface on the printer use parallel HTTP service registrations (same instance name, different type).

(there is also a bunch of "flagship service/protocol" stuff that happens for Bonjour printers, but let's not muddy the waters too much...)

A single print server that represents multiple physical printers will register/advertise a separate print service (and instance) for each printer.

> So the print server is attached to both the wired and wireless networks with

Or even just a single network with multiple IPv4 and IPv6 addresses.

> ...

This is actually not particularly useful.  Knowing which printer the user last used on a particular network is often what you want.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair