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

From: Kevin Arnold <[email-masked]>
Date: Sat, 01 Jul 2000 10:34:53 -0700

I think that dropping the PR lists would actually make our situation here at
Apple even worse (at least until we deploy DAs).  What would extend the
functionality of PR lists is to change them from a string representation of
IP Addrs to using just 4 byte values for those addresses.  This would give
you a potential 4x bump in the number of machines on that list...

Now of course you probably should just slap the back of my hand and tell me
that I should be deploying DAs to take care of so many machines...  (Its
actually pretty amazing how well SLP holds up in a UA/SA environment of
thousands of machines.  The user experience is pretty good considering!) But
I'm coding Apple's DA implementation as fast as I can! ;-)

Kevin
 
> 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: Mikael Pahmp <[email-masked]>
Date: Tue, 4 Jul 2000 14:03:47 +0200

> -----Original Message-----
> From: james woodyatt [mailto:[email-masked]]
> 
> 
> 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.

Allowing more than two comparisons in an '&' operation shouldn't make the filter implementation more difficult. I actually interpreted the draft words as meaning at most one occurence of the '&' operator with any number of comparisons.

/MiP

---

From: Mikael Pahmp <[email-masked]>
Date: Wed, 5 Jul 2000 11:13:59 +0200

Another issue.

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

This could be troublesome. E.g. the printer template defines the abstract service type service:printer and two concrete service types (ipp, lpr). The service is defined so that a printer which supports both protocols, instead of announcing two separate concrete services, only one instance should be announced where the concrete protocol URIs are listed in an attribute.

The attribute may look like this:
    printer-uri-supported = lpr://foo.com> ipp://bar.com
A '>' character is used as separator.

Now to be able to locate an ipp printer, I can't just do SrvRqst for service:printer:ipp. Instead I should do SrvRqst for service:printer and use a filter predicate = (printer-uri-supported=*lpr:*).

If we deprecate wild cards in predicate filters this will not be possible. In this particular case it can be handled by searching for all service:printers and then filter on the client side. It can also be discussed whether this is a good way of defining a service.

However, I can easily find other examples where wild cards in predicate filters may be needed. I therefor suggest not dropping them.

Is wild card support heavy to implement?

I do support dropping wild cards in tag lists, i.e. AttrRqst and SrvDeReg.

/MiP

---

From: Mikael Pahmp <[email-masked]>
Date: Thu, 6 Jul 2000 09:40:03 +0200

> From: Terry Lambert [mailto:[email-masked]]
> 
> 
> > 
> > This supports the elimination of wildcards in tag lists sent
> > with Attribute request messages:
> > 
> >      This is feature only useful if you have free form attribute
> >      tags like
> > 
> >        (username.joe=Joe Moof),(username.fred=Fred Lung)
> > 
> >      You don't know what the attribute tags are a priori, only
> >      that they start with a common prefix for a particular
> >      purpose (like mapping user names to full names).  This is
> >      a very arcane thing, and there's no good reason to burden
> >      SAs and DAs with the feature of being able to process wild
> >      cards in tag lists (like "username*") just so that this sort
> >      of namespace can be returned efficiently.
> 
> I think you can't send duplicate tags with different
> rvalues, can you?

SLP attributes may be multivalued, i.e. have multiple rvalues.
E.g. an attr-list may look like this:
    (username=Joe Moof,Fred Lung)

From a quick glance at the RFC I didn't see any rule against sending the same attribute twice in an attr-list. I think the correct interpretation of it would be to aggregate the rvalues as multiple values to the same attribute.
This example
    (username=Joe Moof),(username=Fred Lung)
would then have the same meaning as the one above. I do recomend having the first notation however.

> 
> How would one ask for an SMTP server willing to relay
> outbound email for a group or user, or an IMAP4 or POP3
> server where mail for a particular user is stored?
> 
> I've personally been using attribute tag suffixes for
> this...
> 

I'm not sure I understand exactly how you're doing it. Having attribute tags with somekind of namespace - prefix.suffix - is perfectly OK. But are you really using wild cards in AttrRqst tag lists (e.g. 'username.*') and do you consider this an important optimization compared to just asking for all attributes?

Example:
The POP service has one multivalued attribute called username which has contains all the user names.

A service request could then be done like this:
   service-type:  service:pop3
   predicate:     (username=Fred Lung)

/Mikael