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

From: James Kempf <[email-masked]>
Date: Wed, 28 Jun 2000 12:00:17 -0700

Re. PR lists, I think we ought to either drop them or keep them. The 
Apple experience seems to be that they are of limited utility, so
I think dropping is probably the best solution. Or, rather, deprecating
them.

		jak
>
>Thanks for the excellent discussion.
>
>Please don't take this email as a 'working group chair's wrap up.'
>Keep the discussion going!  This is just my take on the discussion.
>
>
>1. Limiting search filters to '='
>
>   Your arguments that this would limit the utility of SLP for load
>   balancing are very strong.  Does anyone continue to think that
>   this should be dropped from SLPv2 (as a *required* feature)?
>   I now think this requirement should not be dropped.
>
>
>2. PR lists
>
>   There are several options here to explore:
>
>     2.1. Keep PR lists
>     2.2. Drop PR lists
>     2.3. Drop PR lists but add exclusion lists (as an SLP extension)
>          with a digital signature
>     2.4. Change the interpretation of PR lists so that SLPv2bis and
>          forward SA and DA implementations will keep state so that 
>          they won't reply to the same source address/source port/XID 
>          for the next 10 minutes (say).
>
>   > > > >  - Eliminate PR list support. [3.4.1]   
>   > > >
>   > > >  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.
>   > 
>   > ???
>
>   If there are < 10 services of type T, who cares if there are spurious
>   responses.  SLP messages are pretty infrequently used (boot/app start 
>   time) and multiplying them all by 10 doesn't add up to much on even 
>   1MB links.
>
>   If there are > 100 services of type T, PR lists don't adequately 
>   filter anyway.
>
>   So PR lists are really designed for suppressing repeated responses in
>   networks of 10-100 services of type T.  The thought was that the UA
>   would be overwhelmed by responses, not that there would be too many.
>   Even in the case of 100 services of type T, returning responses over
>   15 seconds to 3 successive multicast requests you have 3 multicast + 
>   100 unicast in the best case with PR lists and 3 multicast + 300 unicast
>   in the worst.  The question is:  Is the complexity of the variable
>   length headers and PR list handling code is worth saving those best
>   case 200 messages?
>
>   I think we could explore 2.4 above, as Mike Day suggested.  Existing
>   SLPv2 SAs and DAs would behave as expected (not replying if they are
>   on the PR list).  New SAs and DAs could filter out that request for
>   a period of time.  Then, a UA could issue a *different* PR list each
>   time and potentially suppress hundreds or thousands of responders
>   (provided they supported the new 'exclusion' rules).
>
>   Mike, can you comment on the success of PDS's exclusion lists?
>
>    
>3. Finding the 'best' service
>
>   This has been discussed in the past.  I think the thing to do is
>   to define a 'Best Server Extension' for SLP.  If the SLP SA or DA
>   supports it, the service reply will have only one service included
>   (and the 'Best Server Extension' so the UA will know it is the best
>   and not the only service.)  If the SA/DA doesn't support this option
>   then the UA can either get services & their attributes and grub
>   through them or do consecutive searches for the best one.  So we
>   wouldn't fix the legacy devices, but supply a forward path for
>   those which want better load balancing capabilities.
>
>
>Erik 
>---------------------------------------------------------------
> Public words and deeds have their own weight and significance 
> quite apart from private motives or secret calculation.
>   - Timothy Garton Ash
>

---

From: James Kempf <[email-masked]>
Date: Wed, 28 Jun 2000 12:02:26 -0700

Re. "best server", I think this would be really hard to define and I don't
see much point in it. If the point is to limit the number of replies, then
that could be achieved in the API for multicast by setting the maximum number of
replies, and it could be achieved for a DA by defining an SLP extension
that told the DA to limit the number of replies.

		jak

---

From: James Kempf <[email-masked]>
Date: Wed, 28 Jun 2000 16:07:48 -0700

Based on my implementation experience with SLP, the real difficulty is
not in handling the parsing of the query, but in implementing the
LDAP semantics for "!". The logic in the query evaluation routine
is pretty torturous. Optimizing the query evaluation may require
a whole separate set of data structures just to support that
operator. 

After that, having to support multiple data types for attributes
(integer, string, etc.) comes next, though it is pretty far down on the
list. Multiple data types also impacts how the service advertisements
are stored in the service table.

Actually parsing the query is pretty much last. A simple handcoded
recursive descent parser in Java is easy to do, with C you can
use the C tools (lex and yacc), though I've not felt the need to
use them in the C++ implementation I'm working on. I've got some
amount of programming language implementation experience, so perhaps
my view is biased, but I think any second year CS student could
do a parser for the SLP query syntax as a midterm assignment.

I understand the desire to keep the SA simple, and therefore limiting
the query semantics would help, but I can see the usefulness of
more complex data types and logical operators for applications like
load balancing and others. And the compatibility with LDAP is a good
feature that smooths adoption in some areas.

My $0.02...

			jak

>Erik Guttman wrote:
>I think that the combination of limiting search filters to '=' and
>limiting  request to at most one '&' operator effectively prevent
>SLPv2bis from being used to balance server loads.
>
>If the WG decides not to drop the requirement for the other comparison
>operators, then some limited applications for balancing server loads
>are possible.  We would still be limited to at most two comparisons in
>an '&' operation, but I am predicting that EBSS will be able to make
>do with that.
>
>Where we need greater search filtering capabilities, we can use LDAP. 
>The whole reason we are using SLP in the first place is to avoid
>saddling LDAP servers with responsibility for handling every last
>piddly little service location request in our distributed OLTP
>system.  Being able to do a little load balancing with SLP search
>filters is potentially a big added scalability win for us.
>
>
>-- 
>j h woodyatt <[email-masked]>  | "Never look at the trombones.
>coder, foundation software        | You'll only encourage them."
>enron broadband switching systems |     -Robert Strauss, on conducting