Subject: Re: [Ips] iSNS: generating SCNs on DD change (Scaling concern)

From: Arpakorn Boonkongchuen <[email-masked]>
Date: Tue, 09 Dec 2003 12:18:37 -0800

Hello All,

My concern for requiring iSNS server to send all affected nodes to
each client is one of scaling.  Pls see my example below.

At 08:40 PM 11/21/2003 +0530, Priya Viswambharan wrote:
>Hi KVS,
>
>Regular SCNs will be generated by the iSNS server to be sent to only those
>iSNS clients that have registered (through SCNReg) for such state changes.
>
>In your example, the iSNS server would send an SCN with the OBJECT REMOVED
>bit set and listing iqn.b and iqn.c as the nodes that were removed. If iqn.a
>wants to be doubly sure about iqn.b and iqn.c being no longer registered in
>the iSNS DB, an iSNS DevAttrQry with the node names as the MessageAttributes
>(plus some operating attributes for the nodes) may be sent for which the
>iSNS server would respond with no values in the Operating Attributes since
>the devices have been removed or have moved to a different DD.
>
>Regards,
>Priya
>
>
>----- Original Message -----
>From: "K. V. Subramaniam" <[email-masked]>
>To: <[email-masked]>
>Sent: Friday, November 21, 2003 4:33 PM
>Subject: [Ips] iSNS: generating SCNs on DD change
>
> > I have a question regarding generation of regular SCNs. When a DD member is
> > removed, or if a DD is removed or if  DDS is disabled, it affects
> > multiple initiators/targets.
> > Do we then generate regular SCNs to each affected node? For example,
> > consider
> > that due to change in DD, iqn.a can no longer access iqn.b and iqn.c, then
> > do we
> >     (a)send an SCN to iqn.a giving the info that some change has occured to
> >     SELF and expect it to query iSNS again
> >     (b) send an SCN giving OBJECT_REMOVED as reason and listing out iqn.b
> >     and iqn.c as the nodes that are no longer visible.
> >
> >
> > Thanks
> > kvs

Finding out all affected node is easy for the case when one node goes
online/offline but it can be computationally expensive for the
case when DDS changes.  To illustrate this, the following steps need
to be performed before sending the SCN:

for (each node x affected by the change in DDS)
    - oldAccessibleSet = set of nodes accessible by x before DDS change
   - newAccessibleSet = set of nodes accessible by x after DDS change
   - diff = difference between newAccessibleSet and oldAccessibleSet
      // difference is really the union of the two sets - the intersection.
    - Filter the result based on whether the initiator has registered
      to receive SCN for initiator/target (and self) only or not
   - Send SCN containing (subset of) the difference to node x

Let us consider an example where a discovery domain set changes with
(a, b, c) (d, e, f) being the initial active DDS and (a, b, e) (c, d, f)
being the DDS after the change.   If all nodes have registered
to receive SCNs, then we have to compute accessibility for each node.
We have to perform 3*2 operations before the DDS change and
3*2 operations after the DDS change. In general, the total
operations required is 2*M*N*K where there are M Active Discovery
Domain Sets, N Discovery Domains in each DDS, and K nodes in each DD.
The load can potentially be significant in a large-scale deployment.

This is different from what happens in the FC fabric where a port
registering to receive a RSCN is sent an RSCN that indicates that
there is a change. The responsibility of getting the change lies
with the port receiving the SCN.   This model alleviates the
workload from the server and thus helps overall scaling by making
all clients handle the difference and filtering computation for
itself.

What does people think?

Regards,
Arpakorn