Subject: RE: comments on requirements draft 04

From: Erik Guttman <[email-masked]>
Date: Wed, 9 Aug 2000 09:34:55 +0200 (MET DST)

>>  6. Service discovery protocol requirements include notification that
>>     a service is going off line.
>
>The excerpts from the draft below say SHOULD, not MUST. NBP, SLP, etc. don't
>include "going-off-line" notifications, but is this a reason that a protocol
>should not do this. (IGMP did not have the concept of leaving a group,
>IGMPv2 does.) To me, a "going-off-line" notification seems like a fine and
>reasonable thing for a service discovery protocol. 

If it isn't in AppleTalk/NBP, Netbios/SMB, nor SLP, why is it so reasonable?   
 There is a similar feature in IPX/SAP which involved updating the available
set of services every three minutes.  This was a major disaster as deployments
grew.  This was the principal reason SAP was abandoned!  Netware v5 uses SLP 
to support the same APIs as SAP - which shows that the going-off-line 
mechanism is not required to support the ***function***.

Other cases where it has been tried is in JINI which has RMI features 
to allow notification to scale (somewhat, since each subscriber gets 
a unicast notification) and SSDP which has no scaling features at all.  
Neither of these protocols are widely deployed and both would have trouble
scaling to networks with many services and many clients.

Experiments with notification in SLP have shown that to do it scalably 
requires significant state be kept in SAs and DAs in order to keep track 
of subscriptions (in order to send going-down notifications only when 
necessary) and the use of separate multicast groups for each notification. 
See 

  draft-kempf-srvloc-notify-03.txt

Feedback on SLP is that it should be less rather than more featureful, 
so requiring this feature will not go over well.  SLP notifications have
been envisioned as an optional extension - only for end to end applications
which really need it.

I therefore argue that we ***not*** require this (even as a SHOULD, which
means 'do it unless there is a good reason not to'.)  Someone MAY support 
this feature - but in this case, it has no place in a requirements document.

Erik

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 09 Aug 2000 09:40:32 -0400

At 03:34 09/08/00 , Erik Guttman wrote:
>grew.  

To Erik's point, @Home was forced to filter out broadcasts on the
NetBIOS/IP ports and also IPX/SAP in its bridged cable modem markets
because the broadcast traffic from each host consumed far far too much
bandwidth and because of some external pressure to "protect users from
being able to see their neighbor's PC via 'network neighborhood'".

While @Home is not a ZeroConf target user, large corporate LANs have 
precisely the same sort of operational issues that @Home experienced.

A periodic broadcast (or better, multicast) from a server is far far
better than having each host or each node send periodic traffic.

IMHO,

Ran
[email-masked]