Subject: Re: Relationship DNS-SD and SLP

From: Rod <[email-masked]>
Date: Tue, 23 Jul 2002 03:47:21 -0700

>On Tue, 23 Jul 2002, Brad Hards wrote:
>>  Or a simpler case (which doesn't require management) - I want
>>  to build a zeroconf printer that is a colour bubblejet that can do
>>  A5, A4 or A3, but not that dodgy American Letter format. What
>>   are the attributes that I should program into its SLP SA or
>>  DNS-SD reporting, or whatever?

"I'm a printer."

>Please see:
>   http://www.iana.org/assignments/svrloc-templates/printer.2.0.en
>
>According to this, the printer would advertise itself as
>
>   service type =  service:printer:ipp
>            URI =  service:printer:ipp://169.254.23.16:631/myqueue
>          scope =  default
>     attributes =  ...,(printer-media-supported=iso-a4,iso-a5,iso-a3),...
>
>and
>
>   service type =  service:printer:lpr://
>            URI =  service:printer:lpr://somehost.example.com:515/myqueue
>          scope =  default
>     attributes =  ...,(printer-media-supported=iso-a4,iso-a5,iso-a3),...

So for something like a file server, I'd want to do something like:

   service type =  service:ftp:ftp://
            URI =  service:ftp:ftp://169.254.23.16:21
          scope =  default
     attributes =  ...,(files=asa.jpg, pag.jpg, chip.jpg, par.jpg, 
tu.jpg, cielo.jpg, par2.jpg, tuno1.jpg, cielo2.jpg,  parque.jpg, 
tunovio2.jpg, marco.jpg, parque2.jpg, usps.jpg, ent.jpg, parque3.jpg, 
via.jpg, experiment.jpg, parque5.jpg, vista.jpg, eye.jpg, 
parque6.jpg, xico.jpg, etc. etc. etc. etc....)

Hey, who needs 'ls'?

Or an even better example, for something like a music exchange 
program or network jukebox software, I would just list the thousands 
of songs in the device's playlist right in the attributes section!

Hmmm...................

What ever happened to the layered approach of solving a problem?

- STEP ONE, SERVICE DISCOVERY PROTOCOL -

- Hi! I want to print. I'm looking for a printer.
- Yo, over here, I'm a printer. I speak <this> protocol.

- END OF STEP ONE -

- STEP TWO, PRINTING PROTOCOL -

- Hi printer! (Handshake.) Can you print in color on size A3?
- Sure, bring it on.

(Prints...)

- END OF STEP TWO -

Isn't this far better than:

- Hi! I want to print. I'm looking for a printer!
- Yo, over here, I'm a printer. I can do sizes iso-a0, iso-a1, 
iso-a2, iso-a3, iso-a4, iso-a5, iso-a6, iso-a7, iso-a8, iso-a9, 
iso-a10, iso-b0, iso-b1, iso-b2, iso-b3, iso-b4, iso-b5, iso-b6, 
iso-b7, iso-b8, iso-b9, iso-b10... oh and I can also print in black 
and white, grayscale, or color... I can use FinePrint or PhotoGrade 
printing, I can print 1, 2, 4, 6, 9, or 16 pages per sheet, I can 
feed paper from cassette 1, cassette 2, manual feed or envelope 
feeder... but that one's out of envelopes right now... I can also 
print collated or not... I can print with low, medium, or high 
quality... you get the idea.

Of course, printing is probably not the best example, since current 
printing protocols are not always sufficient for all that we want 
them to do, but that should be a problem for them (currently being 
addressed by the IPP guys) like Keith mentioned, not the -service 
discovery- protocol.

Even if the requirements on SAs are reduced, it doesn't change the 
fundamental paradigm flaw (for our purposes at least) of looking for 
a service's attributes, characteristics, and capabilities, instead of 
just a simple service instance, which makes everything a lot simpler 
and cleaner. This is where DNS-SD shines.

I think SLP mixes apples and oranges, tries to take over work that 
should belong somewhere else, and reinvents the wheel in some cases. 
I want to look for a file server. After I find one (or several) I'll 
bother with asking it what files it is offering. There are anough 
ways for me to do that already. This same basic concept should apply 
to any service, be it a printer, jukebox server, TiVo, coffee 
machine, etc.

I'll quote Josh Graessley's email:

"The problem with SLP, in my opinion, is that it is overly 
complicated. The complication arises from the goal of advertising all 
of the characteristics of services and supporting very specific 
queries."

And draft-cheshire-dnsext-nbp:

"This could be useful on extremely large networks with very many 
printers, but may be overkill for a small home network with only one 
or two printers."

And even in the extreme case where some narrowing of a list of 
services was strictly required, DNS-SD still provides enough basic 
flexibility to do so without getting too complex:

"6. Selective Queries

    This proposal does not attempt to define an arbitrary query language
    for service discovery, nor do we believe one is necessary.

    However, there are some circumstances where narrowing the list of
    results may be useful. A printing client that wishes to discover only
    printers that accept Postscript over lpr over TCP should issue a PTR
    query for the name "_postscript._lpr._tcp.example.com." Only printers
    that support Postscript should register this PTR record pointing to
    their name.

    Note that the printer's Service Instance Name which this PTR record
    points to is unchanged -- it is still something of the form
    "ThePrinter._lpr._tcp.example.com." The domain in which printer SRV
    records are registered defines the namespace within which printer
    names are unique. Additional subtypes (e.g. "_postscript") of the
    basic service type (e.g. "_lpr._tcp") serve to narrow the list of
    results, not to create more namespace."

Again, I don't have anything against SLP, but I don't think it's 
really the way to go for ad-hoc or home networks, which are the main 
focus of Zeroconf.

Another mistake that I think people are making is mixing up the goals 
and functionality of two different things, Multicast DNS and DNS 
Service Discovery. I've heard phrases like "look up services by name" 
and "name lookups as a solution to finding services on a network" be 
used constantly here. This is fundamentally wrong, and brings a lot 
of confusion. You are not going to look up services by name, or use 
names to find a type of service. You are going to look up a service 
by TYPE (using SRV records with types and, if necessary, subtypes) 
and THIS will return the service's NAME, which you can conveniently 
use to communicate with the device, without worrying about its 
address or if it changes. Even though the DNS protocol is used on 
both cases (in DNS-SD it's mostly out of convenience), these two are 
not the same thing, and DNS-SD is far less limited than it would 
appear by just thinking it uses a 'name to find a service.'

-Rod Lopez

---

From: Brad Hards <[email-masked]>
Date: Tue, 23 Jul 2002 20:56:04 +1000

> >>  DNS-SD reporting, or whatever?
What does this look like in Rendevous? What goes over the wire?

What does the application ask the support libraries?

How would it look for a fax machine?

Brad
-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

---

From: Erik Guttman <[email-masked]>
Date: Tue, 23 Jul 2002 13:00:44 +0200 (MEST)

Rod,

> "I'm a printer."
On many networks you would get a lot of answers back for a query like that.

> parque6.jpg, xico.jpg, etc. etc. etc. etc....)

No one has suggested exhausted listing of content using SLP.
Instead, I might list a relative or absolute path of some 
meaning to an application or installer, or some metadata 
about my files or a description - "Rod's scrapbook", for 
example.  Any of these would help you manually or a program
automatically locate the data.

> - STEP TWO, PRINTING PROTOCOL -

You leave out:
 - No.
 - No.
 - No.
 - No.
 - No.
 - No.
 - No.
 ...

> - Hi printer! (Handshake.) Can you print in color on size A3?

It is not much more complicated is it to process a query for
a type and an attribute=value than just a type.  It is a lot
friendlier on the network and on the client software to not
have each client have to interrogate all servers to find the
one it can use.

Erik

---

From: Rod <[email-masked]>
Date: Tue, 23 Jul 2002 04:28:00 -0700

>On many networks you would get a lot of answers back for a query like that.

I totally agree. That's why I specifically focused my comments 
towards ad-hoc and home network scenarios, where you are much less 
likely to get excessive answers back. And I quoted that excrept from 
draft-cheshire-dnsext-nbp:

"This [...] may be overkill for a small home network with only one
or two printers."

>automatically locate the data.

I agree, I was exaggerating to get my point across, which is that the 
service discovery protocol should not have to deal with all this 
endless sea of attributes and characteristics of services. That's 
what each service protocol is designed for. Mixing them in with the 
service discovery protocol seems like overkill and makes things more 
complicated, overdone, and tedious, in my opinion.

>  - Hi printer! (Handshake.) Can you print in color on size A3?

Wow, that's one rich home. :-))

Again:

"This [...] may be overkill for a small home network with only one
or two printers."

>have each client have to interrogate all servers to find the

It is not more complicated to process, but I don't think that's the 
issue here. There are many technologies that have failed because 
their complexity got out of hand. Not because they were harder to 
process, but because they either were harder to manage, implement, 
understand, tried to accomplish too many things at the same time, or 
a combination of these.

Once again, I think it depends on the context. Like I previously 
stated, in the context I was talking about, which is the one Zeroconf 
focuses on, SLP looks like overkill.

Regards,

-Rod Lopez

---

From: Varuni Witana <[email-masked]>
Date: Tue, 23 Jul 2002 22:25:31 +1000

> "This [...] may be overkill for a small home network with only one
There seems to be some consensus that a zeroconf network may contain
services where the choice of the instance is dependent on its
attributes.
Before we get too fixated on how many printers a person might have in
their home :)
is it possible to quantify how many distinct instances of a service need
to exist before scalability issues with having to query each one in
turn, overcome the perceived complexity of SLP? 

Another question, are we going to have such a clear cut demarcation
between devices meant to be used in fixed networks (which would use SLP)
and devices meant for the home market which would use mdns?
 
Regards
Varuni
-- 
Varuni Witana
Senior Research Engineer                       Email:
[email-masked]
Sydney Networks Research Lab                   Ph: +61 2 9666 0647
Motorola Australian Research Centre            Fax: +61 2 9666 0501

---

From: Erik Guttman <[email-masked]>
Date: Tue, 23 Jul 2002 14:48:50 +0200 (MEST)

> "This [...] may be overkill for a small home network with only one

So, we need a service discovery protocol for the home, for the enterprise,
for the internet, for the distributed object framework, for the telephony
core network services, for the data center, for network infrastructure
discovery?  We end up without any way of coordinating all of these,
keeping them consistent and making sure the approach scales well when
it is (oops!) used a larger network than intended.

Erik

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 23 Jul 2002 14:27:05 +0100

> From: "Varuni Witana" <[email-masked]>
>
> > >>  "I'm a printer."

This is just the issue I am wrestling with. There is no point of demarcation
in the scalability continuum. Lets say I am designing a cheap printer, I
cannot afford the resources to build in every service discovery protocol under
the sun. On the other hand, neither can I afford to say that it won't work
properly when your network grows beyond a certain size or complexity -
customers don't like that kind of thing.

So it seems to me that either DNS-SD has to scale gracefully all the way up to
huge, or that I will have to bite the bullet and build in something tougher
like SLP anyway. And then why would I want to do DNS-SD as well?

Philip Nye

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Jul 2002 11:24:51 -0400

> complicated, overdone, and tedious, in my opinion.

I disagree, to a point.  the service discovery protocol shouldn't have 
to know about the semantics of those  attributes, but it should be able to
advertise those attributes for the benefit of client programs that can
make use of them.

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Jul 2002 11:27:21 -0400

> parque6.jpg, xico.jpg, etc. etc. etc. etc....)

that's a really silly example.  surely nobody expects to use a service
discovery protocol in this way.

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Jul 2002 11:31:29 -0400

> turn, overcome the perceived complexity of SLP?

the v4 LL document has some explicit assumptions about how many hosts are
reasonable for links using LL addresses - 1300 hosts is considered
an upper bound.   so a reasonable test of SLP (or any other candidate 
discovery protocol for use in ad hoc networks) might be: how well will it 
work for networks of 1300 hosts with a reasonable mix of host classes
(workstations, printers, etc.)?

---

From: "Jim Fleming" <[email-masked]>
Date: Tue, 23 Jul 2002 10:40:18 -0500

----- Original Message ----- 
From: "Keith Moore" <[email-masked]>
To: "Rod" <[email-masked]>
> discovery protocol in this way.

That is one of the merits of having the "toy" 32-bit IPv4 Internet for
silly experiments and Proof-of-Concept market trials. Once all of the
testing is worked out, people can move to the more serious and stable
IPv8 64-bit address space, using 128-bit DNS services. People do not
have to be constrained in their thinking by the narrow-minded I* society.
There is a place to expand and grow.

Jim Fleming
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

---

From: Rod <[email-masked]>
Date: Tue, 23 Jul 2002 13:19:16 -0700

>At 11:27 AM -0400 7/23/02, Keith Moore wrote:

I'm glad I got the point across then! ;-)

I liked your comment:

>Sane admins do not try to make their lives more complex than they need to be.

-Rod

---

From: Tim Jansen <[email-masked]>
Date: Tue, 23 Jul 2002 23:35:06 +0200

> I'm glad I got the point across then! ;-)

You didn't, you just showed that it is not very smart to use a service 
discovery protocol when a protocol for distributed searching would be 
appropriate. For example a protocol that sends the query to all service 
agents and they respond to the user agent if they find any matches (BTW it 
would be quite interesting to add this feature to SLP).

bye...

---

From: Rod <[email-masked]>
Date: Tue, 23 Jul 2002 14:51:54 -0700

At 11:35 PM +0200 7/23/02, Tim Jansen wrote:
>appropriate.

I wasn't talking about distributed searching (if I understand you 
correctly). Just a client looking for an ftp service, and a server 
that is advertising its service and also its 'offerings.' (Files in 
this case, which is an example I exagerated on purpose.)

You're right in a way though, that was precisely my intention. To 
make a strong distinction between the processes (and protocols) for 
discovering a service instance, and for discovering said service's 
characteristics, attributes, and capabilities, in order to express my 
point of view about how service discovery should work, with focus on 
Zeroconf networks.

Thanks!

-Rod

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Jul 2002 18:21:29 -0400

> I'm glad I got the point across then! ;-)

Well, I'm not sure what point you were trying to make.   It's certainly
not an argument against a service discovery protocol, nor an argument
in favor of trying to use a variant of DNS to discover hosts on an ad hoc
network.