RE: iSCSI: Wrapping up SendTargets

[Joshua Tseng <jtseng@NishanSystems.com>]

Marjorie,
> 
> Josh,
> 
> > Before you or anyone calls consensus, I would like to see
> > how SLP can solve the following issues:
> > 
> > 1)  Management of Discovery Domains.  You don't want
> > incompatible file systems discovering each other, or
> > very bad things will happen.  Say 'goodbye' to the Unix
> > file system who's host is discovered by SLP....
> 
> This function is the domain of an application value-add, and 
> does not need
> to be specified in the SLP protocol.  It is perfectly feasible for an
> application that provides storage discovery services using 
> SLP to filter the
> information given to a particular initiator based on that initiator's
> identity (just as a target would when responding to SendTargets).  The
> 'management of discovery domains' is a 'storage network 
> management' related
> value-add feature of an application, not something SLP must specify.

If this function doesn't need to be specified, then how do you 
intend to get mixed-vendor environments to deliver this
functionality?  One vendor supplies the target, a different
vendor supplies the initiator, and each vendor decides to
implement their own approach for configuring scopes or
discovery domains.  

Without a standard approach that delivers a full, comprehensive
set of capabilities (management, monitoring, discovery, etc...), 
each vendor will implement their own proprietary approach to
deliver incremental capabilities required to support their
individual iSCSI implementation.  There will not be seamless
interoperability, which would be a setback for iSCSI.  What
we will end up with is the "Tower of Babel".

I don't really care if you call iSNS an "application" or a
"protocol".  The point is, in the interest of interoperability,
we are proposing iSNS as a standard, comprehensive approach.
The operational model has been tested and proven, and it gives
you every capability SLP promises, and far more.  And we have
made the source code available to everyone.

Now why anyone would want to ignore all this and write their
own proprietary application to fill in feature gaps of SLP,
...well that's their own business...

> 
> > 2)  Transfer of X.509 digital certificates.  SLP cannot
> > easily transfer binary entities.  This affects the iSCSI
> > target device's ability to enforce its access control list.
> 
> Again, this may be an application value-add, it's not a 
> requirement for
> storage discovery.  Security infrastructure is painful to 
> administer.  Seems
> to me as if a user would chose a generic security solution 
> using something
> like SCEP protocol, which would work for a variety of 
> applications, not just
> storage.  

iSNS is not a certificate server; it only provides for distribution
of X.509 public key certificates.  Strictly speaking, it is not
"security infrastructure" any more than an excel spreadsheet is.
But iSNS is a useful tool which can be used to store your
security policy, and much easier to use than storing your ACL's
and certificates on excel spreadsheets.

SCEP performs a different role than iSNS.  Indeed, iSNS could
be deployed alongside the SCEP server to distribute certificates
for storage devices.

> 
> > 3)  Monitoring of available devices.  SLP relies upon
> > service agents re-registering periodically, in order to keep
> > the freshness of its database entries.  But this leads to a
> > dilemma: if SA's re-register too often, the DA will be
> > overwhelmed.  And if they register not often enough, then
> > you will have stale device entries.  The fact is, SLP was
> > not designed to be a real-time discovery protocol. But in
> > storage networks, real-time information is crucial, as even
> > slightly out-of-date information can lead to unnecessary
> > logins and other events that will seriously degrade the
> > performance of the storage network.
> 
> I'm not sure I see the need for storage devices to 
> "re-register" themselves
> frequently since storage is not typically a highly dynamic 
> configuration
> environment.  You've made some statements about the real-time needs of
> storage, but without specific examples I don't see how "real-time
> monitoring" is a crucial requirement of a centralized storage resource
> management service.

See below.

> 
> As for your concerns about SA's re-registering too often and 
> overwhelming
> the DA, this "push" model is viewed as having less problems 
> than the "poll"
> model where a centralized application requests status updates 
> from multiple
> devices (but there are tradeoffs with both models).  This is a classic
> networked device monitoring problem, I don't think the group 
> that developed
> SLP would have ignored it in their protocol service design.
>  
> > 4)  State Change Notifications.  This is important to
> > support failover and redundancy capabilities, and to
> > ensure that initiators can persistently maintain their
> > sessions with targets in the event of network topology
> > changes.
> 
> This area of service really applies much more to a Fibre 
> Channel domain than
> an IP/iSCSI domain, due to differences in protocols.  
> Initiators shouldn't
> need notification of target devices "going away", since the 
> TCP connection
> provides that information.  As for devices being added, there 

TCP can take minutes to time out.  The polling iSNS does gives
iSCSI another tool to detect when a device or port has been
disconnected.  Sure, as David pointed out it's not failsafe, since
the iSNS client could still be running fine despite a failed storage
controller.  But it's another tool to detect a failed or
disconnected device.

Otherwise, the alternative is to wait for TCP to time out (several
minutes).  The iSCSI initiator may decide to initiate another SLP query
to see if that device is somewhere on the network.  If the database
is not real-time and up-to-date, this could lead to further delays
before the final action to either abort the session or move it to
different TCP connections using alternate target interfaces.

This is not a major point, but I always thought having real-time
data is better than stale data.  I hope you agree.

> are a number
> of ways to model this, that's another thread of discussion.  On first
> thought, a model where an administrator triggers the update 
> of initiators
> when a target is added, rather than some automatic or polled 
> environment
> seems more desirable to me.  How many OS's can deal with 
> storage suddenly
> "appearing" after initial boot?  It seems that SLP could be used by an
> application to provide this service if it's deemed necessary, 
> it remains to
> be specified "how".
> 
> > Furthermore, it would be helpful if you clarify whether your
> > statements are representing the iSCSI NDT or only of your
> > personal views.  I do not believe your statements regarding
> > the SLP approach for iSCSI are consistent with what was
> > agreed to in the NDT.  I believe the consensus was that both
> > iSNS and SLP are to be considered for discovery.
> > 
> > >   Future - Pursue SLP as the "standard discovery", allowing for
> > >            other solutions such as iSNS as appropriate.
> > 
> > As an NDT member, I cannot support a decision on making any
> > protocol the "standard" without fully addressing the above
> > technical issues. The devil is in the details, and only after
> > exploring such issues will we be able to avoid future pitfalls
> > that may threaten the timely adoption of iSCSI.
> 
> I can't speak for Mark, but I think his intent may have been 
> to express that
> it remains to be fully specified "how" SLP can provide the 
> same information
> as "SendTargets" (we discussed this in the N&D team mtg).  
> Perhaps he didn't
> mean to imply that it would be the only way to discover storage.
> 
> I would speculate that the group/IPS community as a whole has 
> been focused
> on minimal protocol connectivity, and mostly not had 
> time/bandwidth to weigh
> in on the greater "storage directory server" requirements.  
> Nishan has done
> some good work on the iSNS application, the rest of us need 

Thanks!
Josh

> to catch up on
> considering which of it's features are "requirements of a 
> generic storage
> directory server" and which are value-add. 
> 
> Marjorie Krueger
> Hewlett-Packard
>