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

From: James Kempf <[email-masked]>
Date: Fri, 17 Dec 1999 09:22:59 -0800 (PST)

Erik,

Again, thanx for the insightful comments. Replies interspersed below.

-----------------------------------------------------------------------
>
> . 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.
>                 ^^^^^
>

Check.

>   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.
>

We are concerned with people using this to replace polling with
continuous, multicast update on the order of seconds. If lots of
services start doing this in a large network, it could become a serious problem,
though I suppose not as serious a problem as if broadcast were used. 
In a smaller, localized network, it seems like it could be less of
a problem. Perhaps we should just drop this wording and let people's
sense of what works for their network determine how they use the protocol. 

> . 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?
>

Check.

> . 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.
>

We have explicitly designed for robustness. If all DAs are notified
of the subscription, then if one goes down, a UA can roll over to
another without having to update it about its subscription. The
UA only knows that a DA goes down when it contacts it for new
service information, so there could be a significant lag between
when a DA goes down and when a UA with an outstanding subscription
contacts a DA again. During that lag, SAs could come up and the
new DA would not notify them that a subscription was outstanding,
so they would not multicast notifications. Hence, the UA would
be left not being notified about a potentially urgently needed
service.

The problem with multiple DAs multicasting can be solved by having
the DAs snoop for notifications and supress making them if
another DA has already done one. 

> . 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.
>

Yes, this sounds logical. Exponential backoff is definitely called for,
and the TTL algorithm sounds good too. Is this something you thought
of or do you have a reference for it? I'd like to cite any reference
in the doc.

> . 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.
>

Yes, that would help cut down on multicast traffic even further.

> . 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.
>

It makes sense to use MADCAP as you propose, since this would help to
reduce the amount of multicast even further. Only those agents participating
in notification/subscription would use the new multicast addresses.

		jak