Subject: Reactions to draft-guttman-svrloc-slpv2bis-00.txt ???

From: Erik Guttman <[email-masked]>
Date: Tue, 27 Jun 2000 11:28:53 +0200 (MET DST)

Please send feedback on draft-guttman-svrloc-slpv2bis-00.txt

I need to hear from implementors and prospective implementors
of SLPv2 to determine what would be the best steps to take to
move to Draft Standard.

We can add clarifications and drop features.  Any feature which
is not interoperable nor necessary in the protocol should be
dropped on the way to Draft Standard.

The following is a summary of suggestions in the draft.  Please
refer to the draft for details.

 - - - - - - - - - 

Some items are likely to not be very controversial:

 - Limit requests to at most 1 '&' logical operator.  Eliminate 
   support of '&', '|' and arbitrarily nested search filters. [3.1.1]

 - Eliminate wild card support in search filters. [3.1.3]

 - Eliminate attribute requests by type. [3.2.1]
     
 - Eliminate wildcards in attribute tag lists. [3.2.2]

 - Deprecate MANDATORY flags (RFC 2610).  A simplified set of rules for
   deciding what the scope list is is provided.

     See draft-guttman-svrloc-slpv2bis-00.txt section [3.5.1]
     See draft-kempf-scope-rules-02.txt to see how complicated they are
       currently, with support for the DHCP 'MANDATORY' flag.

 - Specify how MADCAP can be used to configure SLP scopes using nested
   administrative multicast scope discovery. [3.5.2]

     I will issue an internet draft which defines this, soon.

 - Eliminate wild cards in the tag list for selective attribute
   deregistration in Service Deregistration messages. [3.6.1]

 - Eliminate the requirement to elide white space in string matching
   for service requests, attribute lists, tag lists, scope lists, etc.
   [3.7.1]

 - - - - - - - - - 

Some proposals are likely to be controversial:

 - Eliminate all but '=' comparisons in search filters.  [3.1.2]

     This makes it impossible to do '(a<=13)' searches - which may 
     make SLPv2 less useful for load balancing, finding optimal 
     servers, etc.  Note that if the client obtains the attributes 
     from servers it can do local comparisons - so this would not 
     eliminate the possibility of load balancing:  It would shift 
     the burden to the client.  The question is:  Is it worth 
     complicating all the SAs for this seldom-used feature?

 - Eliminate AttrRqst and AttrRply entirely, and instead require
   support of attribute list extensions to Service Requests. [3.2.3]

     See draft-guttman-svrloc-attrlist-ext-03.txt

 - Recommend mesh enhancement support to DAs.  [3.4.1]

     Mesh enhancement is nearly ready to be submitted to the IESG for
     consideration as an experimental RFC.  As an experimental RFC it
     would not be possible to recommend it (in a standards track RFC).

     I think it would be best to experiment with it in the field before
     advancing this protocol to proposed standard.  What do you think?
 
     See draft-zhao-slp-da-interaction-06.txt

 - Eliminate PR list support. [3.4.1]

 - - - - - - - - - 

Erik

---

From: Evan Hughes <[email-masked]>
Date: Tue, 27 Jun 2000 10:19:00 -0400 (EDT)

On Tue, 27 Jun 2000, Erik Guttman wrote:
...
>    support of '&', '|' and arbitrarily nested search filters. [3.1.1]

 Would this really reduce complexity? Building the parse tree for the
predicate list is a recursive action (ie, if you can do it once, you can
do it again); limiting to one level of nesting would not dramatically
reduce complexity in the code. 

...
>      the burden to the client. 

  It divides the responsibility between the SA/DA and the UA -- they would
each be somewhat responsible for attributes searching.

> The question is:  Is it worth complicating all the SAs for this
> seldom-used feature?

  Search filters are a good way of reducing network traffic. Consider the
following situation:

 A company has a few hundred printers on the same network, with varying
page-per minute (PPM) values. A UA wants to print to one with a relatively
fast PPM, something better than 10. The UA has two options:

 1. Find all of the printers. Then request their attribute lists. Then go
through each list of attributes (locally), and prune out the slow
ones. This is undesirable since there will be high network traffic, and
the client will have to do a lot of local processing -- for desktop
computers this isn't a large issue, but consider a wireless palmtop:
it has limited battery life (for network usage) and limited processing
resources. 

 2. Start with a PPM of 10 (ie, the predicate would be
(pages-per-minute=10)), and start incrementing (
(ppm=11),(ppm=12),(ppm=13)...). Again, a waste of network resources. 

 With stronger search filters the UA would only have to do a limited
binary search (ie (ppm<=120),(ppm<=60),(ppm<=30)), stopping when it had
two or three responses. 

>  - Recommend mesh enhancement support to DAs.  [3.4.1]

 Sounds good. 

>  - Eliminate PR list support. [3.4.1]

 Wouldn't this cause a lot of spurious responses?

e

---

From: Erik Guttman <[email-masked]>
Date: Tue, 27 Jun 2000 17:29:53 +0200 (MET DST)

> reduce complexity in the code. 

In my experience, and those of other implementors, it was not easy to
build a simple general purpose query parser and interpreter which was
also memory efficient.  This is one of the chief 'complexity' issues
people have mentioned about SLP.

> binary search (ie (ppm<=120),(ppm<=60),(ppm<=30)), stopping when it had

I agree.  But if you were to send out one service request with an attr
list request option, you could get all the attributes back in one round
(conceivably) and make your own determination.  This assumes the attribute
list would fit into the service reply and you were using the attribute 
list extension, etc.
 
>  Wouldn't this cause a lot of spurious responses?

In networks with few nodes, it doesn't matter if there are spurious
responses.  In networks with many nodes, the PR lists don't work anyway.

While visiting Apple I saw PR lists which were greater than 100 entries
long and 100s more responded to repeated requests.  In practice, the
UAs were able to receive and process > 100 replies.  (They are *fast*
machines, though.)

As long as SAs *really* randomize the time they return replies there
should be enough time for UAs to process many responses, without needing
to weed them out using PR lists.

That's why I question the utility of this feature.

Erik

---

From: Evan Hughes <[email-masked]>
Date: Tue, 27 Jun 2000 11:52:27 -0400 (EDT)

...
> list would fit into the service reply and you were using the attribute 

  It also assumes that network resources are cheap, that isn't the case on
wireless networks -- network uses drains batteries. Is it really a good
idea to force the UA (which may will be a low-end PDA) to wade through an
arbitrary number of replies? 

> responses.  In networks with many nodes, the PR lists don't work anyway.

  Could the SA/DA remember the XRI of the message for a short period of
time (10 seconds-ish) and drop all requests with the given XRI?

e

---

From: Erik Guttman <[email-masked]>
Date: Tue, 27 Jun 2000 18:30:28 +0200 (MET DST)

> arbitrary number of replies? 

Doing client side query handling increases the complexity of clients and
burdens the network.  It also relieves the complexity of servers.  Since
most of the criticism of SLP is that SAs must be complex I wanted to evaluate
this trade off.

> time (10 seconds-ish) and drop all requests with the given XRI?

This is a good idea and was part of the PDS (ping discovery service)
implemented by Intel in the mid 90s.  They called it 'previous responder
exclusion lists.'  The problem with exclusion lists is that an attacker
could send requests with an exclusion list from a spoofed source address.
Then the genuine client, who owns the source address, would not be able
to discover services.  Without IPSec this mechanism is only deployable
on networks where you don't worry about trivial denial of service attacks.
It is certainly not something we can standardize at the IETF.  Nice try
though :-)

Erik

---

From: Michael Day <[email-masked]>
Date: Tue, 27 Jun 2000 18:04:17 GMT

You could sign the exclusion lists, though, with a key that is signed 
by a trusted certificate authority. you could also make the exclusion 
list valid only for the XID contained in the message. Then the ability 
to mount a denial of service attack is narrowed to almost nothing. 

Mike Day

---

From: Terry Lambert <[email-masked]>
Date: Tue, 27 Jun 2000 12:10:53 -0700

Erik Guttman wrote:
> Evan Hughes wrote:
> > >  - Limit requests to at most 1 '&' logical operator.
> > >    Eliminate support of '&', '|' and arbitrarily nested
> > >    search filters. [3.1.1]
> >
> >  Would this really reduce complexity? Building the parse
> > tree for the predicate list is a recursive action (ie, if
> > you can do it once, you can do it again); limiting to one
> > level of nesting would not dramatically reduce complexity
> > in the code.
> 
> In my experience, and those of other implementors, it was not
> easy to build a simple general purpose query parser and
> interpreter which was also memory efficient.  This is one of
> the chief 'complexity' issues people have mentioned about SLP.

Despite this, I concur with Evan.  I personally would like
to reuse my LDAP search filter code, verbatim.

I understand that most SAs will not be LDAP servers, but I
would argue that most DAs will (if they are properly
implemented, given the amount of work that's going into
joining the namespaces).

Minimally, I would like to see this be a limitation of SAs
_only_, so that DAs do not have the same restrictions.  I
think leaving this out of SAa, however, will make it very
likely that you will see UAs that only like to talk to DAs
because of the lesser capabilities of direct SA<->UA data
interactions.

I think the complaint here is more one of an implementation
issue particular to the Java language.  I think that a JNI
implementation need not have the limitations that throwing
a lot of data out of scope would cause for a pure Java
implementation.  If we look at symbolic link expansion using
function based unroll in UNIX systems, we have a model that
can satisfy the _apparent_ recursion requirements, without
actually needing stack recursion.

For pseudo recursion to work in this case, the attributes
will need to be stored in sorted order, so that all the
machine appling the patter need do is directed lookups with
an operator stack in hand (instead of a full expression
stack).  I don't think that's a big onus for an SA.

> > >      This makes it impossible to do '(a<=13)' searches -
> > >      which may make SLPv2 less useful for load balancing,
> > >      finding optimal servers, etc.  Note that if the
> > >      client obtains the attributes from servers it can do
> > >      local comparisons - so this would not eliminate the
> > >      possibility of load balancing:  It would shift the
> > >      burden to the client.

This seems painful.  The first widely deployed use of SLP
was, I think, Novell's load balancing gateway product.

> > > The question is:  Is it worth complicating all the SAs
> > > for this seldom-used feature?

I think it is.  The biggest constraint is going to be on UAs;
not only are there going to be more of them (#UA > #SA > #DA),
they are going to be the most resource constrained of all the
agent environments.  The DAs will be the least resource
constrained, at least as far as comput resources, as opposed
to network pipes.  The SAs seem to fall somewhere in the
middle.

I would actually say that the static configuration requirement
is a much bigger burden on the devices that will act as SAs,
since it requires them to have additional user interface for
something that would probably be better handled through one
of the stateless autoconfiguration mechanisms.  I will have to
add a web browser management or an LCD and keypad to my new
printer design to accomodate this.

> > Search filters are a good way of reducing network traffic.
> > Consider the following situation:
> >
> >  A company has a few hundred printers on the same network,
> > with varying page-per minute (PPM) values. A UA wants to
> > print to one with a relatively fast PPM, something better
> > than 10. The UA has two options:
> >
> >  1. Find all of the printers. Then request their attribute
> >     lists. Then go through each list of attributes (locally),
> >     and prune out the slow ones. This is undesirable since
> >     there will be high network traffic, and the client will
> >     have to do a lot of local processing -- for desktop
> >     computers this isn't a large issue, but consider a
> >     wireless palmtop: it has limited battery life (for
> >     network usage) and limited processing resources.

It seems to me that this could be addressed by restricting
the responses to a "yes/no" response.  This appears to be a
requirement for a DA to get this functionality, since what
is really wanted is an aggregate answer to the question "Is
there a resource which satisfies my search criteria?".  The
response to a "yes" answer would be to reissue the request,
asking "Out of the resource(s) which satisfy my search
criteria, please give me one".

In reality, I think that it's probably much more likely that
PDA batter life based on network usage drain is going to be
a real issue; BlueTooth addresses the 802.11 requirements
for power by replacing them with a low power model, and is to
all apearances headed for standardization.

I would say that a much more realistic wireless request
would be for a laptop to request access to display services
in a confernce room for the purposes of a presentation,
where the projection equipment is some variant of a VNC
client.  This would certianly be used widely at IBM, were
the technology readily available; since many IBM sites are
already on Aeronet (Foster City, Almaden, Watson, etc.).

Palm Pilots, on the other hand, don't readily lend themselves
to the idea of needing an 8.5x11 page printer, since they
can't even really utilize or represent the resolution, at
least without pan-and-scan.

SLPv2 seems much more likely to be involved in pervasive
networking and DHCP-less autoconfiguration of transient and
not-so-transient network participants.  Network access in
airports, visitors to wireless-enabled facilities, etc..

> > (ppm=11),(ppm=12),(ppm=13)...). Again, a waste of network

Yes.  But this is a bogus example.  You have a requirement.

With the more complex search filters, you could create an
agregate search that could be satisfied, at least by a DA,
in preference based on order of operation, e.g.:

	(|(ppm>=13)(|(ppn>=12)(ppm>=11)))

And so on.  As long as the precedence order was required to
be followed in presentation order, this is a problem of:

1)	Getting a limited (preferrably 1, but that would
	require a DA) number of responses back, and

2)	Constructing correct search requests

Even a simplified (though I dislike the idea intensely)
search filter syntax, as has been suggested, could handle
this, by appling an implicit rule that, for a criteria of
(ppm>=11), 13 is a better match than 11 or 12 because of
the direction of the open end on the comparison.

Personally, I think clients that request resources with
compound constraints like "I want the fastest color printer"
will get what they deserve: placement in the deepest queue
on the fastest printer with everyone else trying to get the
fastest possible printer.

This is a print queue management problem, and I believe that
it is outside the scope of SLP; these people do not in
actuality want the fastest printer, they want the quickest
printout.  Assigning jobs to printers capable of fulfilling
the jobs in such a way as to optimize this ("I need a minimum
resoloution of QxR, it needs to be color, it needs to be
double-sided, and I'm in building 'B'") is a matter of
queuing policy.

Really, these people should be making SLP requests for a
queue policy manager gateway to serve the request, not for
a printer, per se.

> >  With stronger search filters the UA would only have to do
> > a limited binary search (ie (ppm<=120),(ppm<=60),(ppm<=30)),
> > stopping when it had two or three responses.
> 
> I agree.  But if you were to send out one service request with
> an attr list request option, you could get all the attributes
> back in one round (conceivably) and make your own determination.
> This assumes the attribute list would fit into the service
> reply and you were using the attribute list extension, etc.

Neither one of these adresses the PDA network traffic issue
that is purported to be the problem under scrutiny.

I submit that "best" is a policy decision for the site, and
not a user preference item.

If we want "best", then we should arrange to have the "best"
response come from an SA aggregator -- a DA -- based on
both the request, and on configured site policy.

> In networks with few nodes, it doesn't matter if there are
> spurious responses.  In networks with many nodes, the PR
> lists don't work anyway.

???

> While visiting Apple I saw PR lists which were greater than
> 100 entries long and 100s more responded to repeated requests.
> In practice, the UAs were able to receive and process > 100
> replies.  (They are *fast* machines, though.)

Ugh.

> As long as SAs *really* randomize the time they return
> replies there should be enough time for UAs to process many
> responses, without needing to weed them out using PR lists.

This still doesn't address the issue (which I think is a
strawman, BTW).

In conclusion,

1)	Don't change the search filters to limit them; there
	are approaches which can keep them from bloating out
	memory.  If memory is really an issue, perhaps the
	SA needs to have the ability to send out "partial
	match, but your filter is too complicated for me".
	My own preference: 1k of RAM for an SA is cheap, and
	implementors should not be permitted to create unwilling
	SAs.

2)	The constrained printer SA requests are a special
	case, which I think arises from "we have a printer
	service definition, so lets use it for everything";
	I don't think that a real device would benefit from
	the printer schema definition in the presence of a
	sufficient number of choices.  In particular, I
	think the "problem" will only arise in the absence
	of a DA, which is to say, it will not arise in
	practice.

3)	The PDA example can be adequately addressed by making
	rules about DA return values.  LDAP handled this with
	scoping; either the search syntax can be extended, or
	scoping can be implied (i.e. a request from a PDA would
	want one "best" response, not all responses).  This
	could also be implied by an explicit (new) DA
	configuration option.

So it seems to me that very little wants to change, but it
might be a good idea to allow DAs to be configured to constrain
responses.

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: Evan Hughes <[email-masked]>
Date: Tue, 27 Jun 2000 16:46:51 -0400 (EDT)

On Tue, 27 Jun 2000, Terry Lambert wrote:
...
> least without pan-and-scan.

<imho>
  You don't print data stored on the pilot, you use the pilot as an
interface to the network to tell your "home" computer to print something
stored there on a local printer. The PDA is simply a window onto the
network (until a better UI is designed =).
 </imho>

> airports, visitors to wireless-enabled facilities, etc..

  This is the primary interest of my advisors. They want to use SLP for
service discovery in wireless networks. One of their key interests is the
ability of SLP to send requests that can specify a quality of service
(QoS) characteristic. Removing predicates (in a strong sense, as opposed
to a weaker sense of simple equality) makes SLP useless to their
applications. In the grand scheme of things this isn't a big deal, but I
think it's an unnecessary neutering of an otherwise useful protocol. 

...
> that is purported to be the problem under scrutiny.

  My intent was to illustrate the scale of this decision. Moving attribute
searching off of the SA/DA forces the UA to act like a DA: it must gather
the attributes of all SAs, compare them, and come to a decision. The
alternate approach is to farm the work out to the SA/DA.

  I'm operating under the assumption that resources are allocated in the
following manner:

  DA > SA > UA

  As to finding a fast printer (not necessarily the fastest =), I am
willing to concede that my algorithm may not be optimal. =)

  Someone (Terry?) suggested allowing SAs (and maybe DAs) to tell a
searching UA that the request sent is too complex. This sounds like a good
idea. 

e

---

From: Evan Hughes <[email-masked]>
Date: Tue, 27 Jun 2000 16:49:50 -0400 (EDT)

RE: PR list
> It is certainly not something we can standardize at the IETF.  Nice try

  Wouldn't the security field of the sender mitigate this problem?

e

---

From: Erik Guttman <[email-masked]>
Date: Wed, 28 Jun 2000 10:02:20 +0200 (MET DST)

Evan,

> RE: PR list
> > The problem with exclusion lists is that an attacker

There is no security field in the request messages.  One could be added
(say in an extension).  But owing to the very limited deployment of SLP
security (zero?) I suggest that this would not be the right way to go.

Erik
---------------------------------------------------------------
 Public words and deeds have their own weight and significance 
 quite apart from private motives or secret calculation.
   - Timothy Garton Ash