Subject: re: draft-kempf-srvloc-notify-01.txt

From: Erik Guttman <[email-masked]>
Date: Fri, 17 Dec 1999 16:37:26 +0100 (MET)

Jim, Jason,

This is a review of your draft "Notification and Subscription for SLP".

I first want to say that I really like the draft and the design.  (You 
guys might want to say something to the list about your implementation
experience.)  The highlights are that notification can be scaled very
well since once DAs are deployed that support the feature, separate
groups will be set up for each subscription and notifications will only
be sent in very specific cases (using filtering). 

-----------------------------------------------------------------------

 . Wording change

     Ideally, these applications would like to be notified when a new
     SA comes up, when an SA disappears or when a service advertisement
     ^^                   ^^
     times out in a DA, and when an SA adds, deletes, or changes the value
     of its attributes.

   SA -> service 

   Applications do not care about SAs, they care about the services
   that SAs advertise.

 . typo & uncertainty...

     An explicit nongoal of the design is to support notification
     frequencies on on the order of seconds or even a few minutes.
                 ^^^^^

   I think that for user interaction, we want to see notifications
   well within a minute (if not a few seconds) for things we care about.
   That could well be localized - that is for services which are 'close'
   we want information quickly, for services that are 'far' we can wait
   a lot longer.

 . mention more:

     In networks without DAs, UAs are notified by an SA when the SA
     initially appears, if any change occurs in attributes, and when the
     SA disappears.

   The reason you do this is so that UAs will know about the list of
   service types that the SA supports.  Why not say this right up front?

 . Notes on multicasting SrvReg messages

   SAs should set the 'fresh' bit if it is a 'new' reg, not set 
   it if it is an update.  In either case, the entire list of attributes 
   of the service should be included.  Note that services which use this 
   notification scheme must have small attribute lists (to fit into
   a single UDP datagram).

 . What happens when there's more than one DA in a scope?  Should the
   subscription notice be sent to all of them?  Won't there then be
   multiple multicast addresses allocated for the same request?

   In section 10:

     UAs that are concerned about receiving
     notification of absolutely every service that appears SHOULD issue
     subscriptions to every newly discovered DA that supports the scopes
     it supports.

   I am concerned by this.  I think UAs should issue subscriptions to
   no more than 1 DA at a time.   DA failure is an exceptional case.
   If we allow the normal case to be one where multiple subscriptions
   can be made (and thus duplicated notifications!) we are not doing
   the right thing.

 . scaling SA-based notification

     The DA and SAs use a multicast transmit algorithm similar to that
     used for discovering services in SLP, described in RFC 2608 [1],
     except the agent performing the notification doesn't wait for
     replies.  The agent performing the notification transmits a
     notification message periodically over an interval of 15 seconds.
     The number of retransmits should vary according to network
     congestion, but a minimum of 6 and a maximum of one per second is
     recommended.

   A SA should only multicast the SrvReg or SrvDereg once, or at most
   a very few times backing off exponentially in time. Subsequent 
   multicasts of notifications should have very small TTLs, even 1.
   I suggest that each retransmission divide the TTL by 8 at a minimum.
   Then you'd have 255,16,2,1,1...

   That way the 'nearby' clients will more 'reliably' see notifications.
   Remote clients may not see them, but we won't toast the network.

 . I believe that notifications should not be sent when services are
   'reregistered' that is when registrations are refreshed to keep them
   from timing out.  That is not stated clearly in the draft.  UAs should
   assume that service registrations are good until they see a dereg.
   If they are really concerned - the UA can issue a service request for
   the service at the time that the 'lifetime' would expire.

 . Notes on use of MADCAP

     If the MAAA infrastructure is deployed, the MADCAP servers MUST
     be configured with multicast scopes to support SLP scopes.  

   Another way of saying this is that DAs and SAs can use MADCAP to
   discover their scope, since the scopes will be the same (MADCAP
   assigned admin scopes == SLP scopes).  

   More should be said here.  The name of the admin scope supplied by
   MADCAP *is* the scope name (which can be put in SLP messages).  The
   SLP mc address for the scope (SAs and DAs join it, requests are sent
   to it) is a -2 offset from the top of the range.  This is explained
   in RFC 2608, but not fully since MADCAP had not yet been standardized!

     Each 
     SLP scope MUST correspond to a multicast scope name, in the sense
     of [7].  In such a case, a DA obtains the base multicast addresses
     and ranges for the SLP scopes it supports using MADCAP. The multicast
     group address used for SLP notifications is at the IANA-assigned
     fixed offset of 2 below the last multicast address in the scope, as
     described for SLP in [6].  This is the same address used for other
     SLP multicasting in administratively scoped networks.
  
   Why not have the DAs allocate a new group for multicasting notifications
   using MADCAP, presuming MADCAP is available?  That is, if scope X has
   address range 239.1.0.0 - 239.1.255.255 then the SLP address for the
   scope would be 239.1.255.253, but the notification address for a particular
   subscription could be 239.1.2.23, for another subscription it could be
   239.1.6.3, etc.  

   The problem with the above is that every SLP agent in the scope is a 
   member of the SLP group.  Multicast is designed to allow sessions to
   be created (especially using MADCAP) so that only those agents which
   care will receive the multicast message.  Multicast routing ensures
   that the minimum of networks have to carry such messages.  In short,
   this is a great opportunity to do the right thing :-)  The only problem
   I see is that each subscription will use up one multicast address
   allocation.  The lease can be set up with the same duration as the 
   subscription, so these will be 'recycled.'  Further, if there are 
   no more, hosts can resort to using the SLP group as a last resort.

Erik