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

From: Erik Guttman <[email-masked]>
Date: Wed, 28 Jun 2000 09:54:37 +0200 (MET DST)

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: Michael Day <[email-masked]>
Date: Wed, 28 Jun 2000 15:40:04 GMT

On 6/28/00, 7:54:37 AM, Erik Guttman <[email-masked]> 
wrote regarding Re: Reactions to draft-guttman-svrloc-slpv2bis-00.txt 

>    Mike, can you comment on the success of PDS's exclusion lists?

exclusion lists worked extremely well at reducing traffic for 
broadcast/multicast convergence, which was the only discovery method 
in PDS. We found that we could achieve convergence very quickly 
(around 100 ms) on an large intranet. The efficiency came from two 
factors. First, the number of responses that the requesting agent 
needs to process is reduced. second, the request can be recast without 
modification (no additions to the pr list, no message reformulation). 

The exclusion list is actually an exclusion request in PDS; that is, a 
distinct message in the protocol. We used it two ways - as a unicast 
message with no address list, and as a multicast/broadcast message 
with an address list. If an agent received a unicast exclusion message 
it would not respond to the source address for a number of ms 
indicated in the message. If an agent received a broadcast/multicast 
exclusion message, it looked for its own address on the address list 
and, if it found itself on the list, would not respond to the source 
for the number of ms indicated in the message. 

PDS is still in use in Intel manageability software and numbers in the 
millions of nodes today. The exclusion list has proven to be effective 
and robust, albeit wide open to spoofing.

The big problem, as Eric pointed out, is the denial of service attack. 
This is why the exclusion list did not make it into SLP v2. Signing 
the exclusion list would prevent the denial of service attack. 
However, because of key management issues it maybe should be an 
optional feature. Or, exclusion messages could be part of the standard 
protocol with signatures an option. 

On the surface, key management issues would be the same as for 
protected scopes, with one significant difference: Uas would need the 
ability to sign messages. Right now they only need the ability to 
verify signatures!

An SLP exclusion message should have an XID field to suppress 
responses to a specific request from a specific source. And it should 
have a time interval, so that the requesting agent can control how 
long responses will be supressed. Only the requesting agent knows how 
quickly it will try to complete the multicast/convergence, so it 
should control the suppression period, within limits set by the protocol. 

One more note: having nodes unilaterally suppress responses will make 
the multicast/convergence method less reliable. A node cannot assume 
that a UDP response message was received by the requester and 
unilaterally suppress responses to that requester for an interval. The 
requester may not have received the response, in which case it will 
never receive the response!  The exclusion list allows the requester 
to suppress responses based upon messages it has actually *received*, 
rather than message that have been sent but not necessarily received. 

Mike

---

From: Evan Hughes <[email-masked]>
Date: Wed, 28 Jun 2000 11:18:11 -0400 (EDT)

Here's another possibility. Could mesh-enhanced DAs assign themselves
unique identifiers and build the PR list out of those? If the signature is
an arbitrary number of bits, the size issue would be avoided for a short
term at least. 

e

---

From: james woodyatt <[email-masked]>
Date: Wed, 28 Jun 2000 12:29:50 -0700

>    I now think this requirement should not be dropped.

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