Subject: RE: service discovery characteristics

From: Jim Busse <[email-masked]>
Date: Mon, 1 May 2000 15:31:29 -0700

Does anyone have the concern about supporting low-bandwidth network physical
layers when considering service discovery?

Consider the home net with a usual stereo/TV system connected to the HomeRF
network as the environment.  In to this configuration walks a guy with a
notebook and an Acer or Intel Bluetooth PC-card.  I think all the
tuner/tone/changer/channel/etc characteristics that will get reported may
make the bluetooth physical layer inoperable for a significant period of
time.  If the characteristics get reported using a verbose XML message, that
will extend the delay even further, I think.

Myron, do you remember the delays we saw when getting bus-resets
interconnecting 3 devices on IP/1394 plugfests?  And that was a 400mbit
physical layer.

Or maybe we don't care about low-bandwidth physical layers?

Jim Busse

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 28, 2000 1:27 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: service discovery characteristics

> -----Original Message-----
> From: EXT Richard Johnson [mailto:[email-masked]]
> Sent: Friday, April 28, 2000 3:51 PM
> To: Hattig, Myron
> Cc: [email-masked]'
> Subject: Re: service discovery characteristics
> 
> 
> Hattig, Myron writes:
>  > I think characteristics SHOULD be supported. 
> Characteristics allow for
>  > refined queries so that things like color printers can be 
> discovered instead
>  > of just printers. The alternative is to discover all 
> printers then negotiate
>  > with each to determine whether it supports color printing 
> or not. In my
>  > simple view of the world this seems pretty obvious that 
> characteristics
>  > SHOULD be supported by a service discovery protocol. Can 
> someone enlighten
>  > as to why this is such a debatable topic?
> 
> Ok, I'll try:
> 
> Discovering that a printer *exists* and finding out the
> *characteristics* of the printer could be separated.  Once you start
> down the road of "characteristics", there no end to what could be
> done.  (Does the printer have 2 or more paper trays?  How much paper
> is in the paper trays?  What type of paper does it print on?  How fast
> does it print?)  Afterall, what if I'm printing a large job (want
> something which prints fast), on a special type of paper (want to know
> what type of paper is in the trays), and I want it printed *now* (want
> a printer which doesn't have any jobs running currently)?  Maybe
> characteristics should be done using SNMP?
> 
> Anyway, that's an argument against including characteristics in
> service discovery.  (Flame retardant suit in place.)
> 
> Of course, it's also a matter of how you define the device types.
> Your list could consist of "CPU", "printer", "video recorder", etc.,
> or it could consist of "CPU", "color printer", "b&w printer", "hard
> disk video recorder", "VCR".
> 
> /raj

I guess I still don't understand. Assuming a device is free to 
to advertise only its name, what difference does it make whether 
other devices choose to advertise a large number of characteristics?

One argument related to yours is that the query language for 
characteristic-enabled queries is too complex for simple devices.
These days this is only true for the most simple of devices and the
most complex of query languages. It seems likely to me that any device
that can handle an IP stack has the computational power to handle
resonable query processing.

Perhaps I am getting old, but I think I have heard this debate many times 
before. It seems like everytime someone invents a successful, scalable 
(more than a couple hundred nodes) namespace, they discover that a flat name

space is too hard to navigate. "Characteristics" aren't the only approach,
but 
they are a good one.

Franklin Reynolds

---

From: [email-masked]
Date: Tue, 2 May 2000 11:04:04 -0500

I am quite concerned about low-bandwidth networks, especially
bluetooth. However, I am not sure I understand the basis for your
concern. It sounds to me like you are suggesting either:

a) that the arrival of a new host would trigger a flood of 
XML-based, advertisement messages from each device/service.

b) the ability to send a query that matches all devices and
returns all the characteristics of any matching device could
cause a network flood.

In the first case, I don't understand why an SLP-like approach 
to characteristic enhanced queries results in advertizement 
induced overload. 

In the second case, this is not a low bandwidth network problem,
this is a scaling problem which would show up in fast networks,
if there were a large number or devices. Characteristic reporting
for a large number of devices relative to available message processing
power, will always be expensive. The question
is whether you allow wildcards or you force the client to ask
each device to report their characteristics individually.

This is separate from using characteristics (like SLP) to modify 
selection. Selection without characteristic reporting is less
likely (though it is still possible) to overwhelm a network.

Franklin

> From: EXT Jim Busse [mailto:[email-masked]]
> Sent: Monday, May 01, 2000 6:31 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: James Kempf <[email-masked]>
Date: Tue, 2 May 2000 09:26:02 -0700

>to characteristic enhanced queries results in advertizement 

For a system based on client-query like SLP, the delay would only happen if the 
the arriving client made a blanket query upon arrival rather than performing
the query on demand, as applications required access to the services. In addition,
the actual amount of data will depend, as Jim originally noted, on the
the data format in which the advertisments are transmitted. Something 
verbose like XML will place a heavier load than a more compact representation.

		jak