Re: iSCSI MIB Object Model

[Mark Bakke <mbakke@cisco.com>]

Matt brought up the same thing, about not having LU and
LUN info.  If we can get a SCSI MIB done quickly enough,
that might give us the visibility we would need for these,
and perhaps we could take them out.  I am hoping to get
a strong WG consensus on this next week.

--
Mark

Somesh Gupta wrote:
> 
> Mark,
> 
> What you propose is what I was thinking of. I would
> expect this info to be the most useful part.
> 
> My preference would be to not have per LU and per LUN
> info at all, even optional (at the transport level).
> Just because it is visible is not a good reason.
> 
> This issue is really something to be addressed at a
> higher level, and if they don't have it yet, maybe that
> is just fine.
> 
> Regards,
> Somesh
> 
> > -----Original Message-----
> > From: mbakke@cisco.com [mailto:mbakke@cisco.com]
> > Sent: Thursday, March 15, 2001 12:29 PM
> > To: someshg@yahoo.com
> > Cc: Venkat Rangan; IPS; jmuchow@cisco.com
> > Subject: Re: iSCSI MIB Object Model
> >
> >
> > Somesh-
> >
> > We are looking into making the LU and LUN tables optional,
> > which would help in this case.   I will bring up the appropriateness
> > of including them at IETF next week.
> >
> > I like your idea of keeping track of the last few LUN errors.
> >
> > I assume that you would like to see something like:
> >
> > 1. Each target includes a list of errors; the target would fill
> >    in something like the timestamp, LUN, and initiator WWUI that
> >    caused that error last.
> >
> > 2. Each session includes a list of errors, and does a similar
> >    thing.
> >
> > Does this sound reasonable?  Do you have other ideas for doing
> > this that would simplify finding out what went wrong with LUs
> > and LUNs?
> >
> > --
> > Mark
> >
> > Somesh Gupta wrote:
> > >
> > > Mark,
> > >
> > > > -----Original Message-----
> > > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > > > Mark Bakke
> > > > Sent: Wednesday, March 14, 2001 12:49 PM
> > > > To: Venkat Rangan
> > > > Cc: IPS; jmuchow@cisco.com
> > > > Subject: Re: iSCSI MIB Object Model
> > > >
> > > >
> > > > Venkat-
> > > >
> > > > You have captured many of our open issues in this
> > > > message.  Please see my comments below.
> > > >
> > > > Thanks,
> > > >
> > > > Mark
> > > >
> > > > Venkat Rangan wrote:
> > > > >
> > > > > Mark,
> > > > >
> > > > > The UML is very nice, and the new object model, covering both
> > > > > Initiator and Target instances is also nice.
> > > > >
> > > > > Overall, we do have some concern over the need for maintaining
> > > > per-LU and
> > > > > per-LUN statistics. In some iSCSI implementations, the
> > iSCSI entity is
> > > > > merely an intermediate layer, with no knowledge of LUs and
> > LUNs. Placing
> > > > > this in the GeneralInfo category and making it mandatory
> > would add undue
> > > > > burden on these implementations.
> > > >
> > > > One of our open questions is "how much is too much?".  We added the LU
> > > > and LUN statistics for a few reasons:
> > > >
> > > > 1. The iSCSI layer does see the LUN; it is included in the
> > SCSI Command
> > > >    message.
> > > >
> > > > 2. For implementations that include the actual target and LUs, such
> > > >    as storage controllers, there is no other way to get information
> > > >    on LUNs through SNMP, since there is no SCSI MIB.
> > > >
> > > > 3. We felt that in this case customers might require LU- or LUN-level
> > > >    accounting.
> > >
> > > I just did a rough (very rough) calculation for the amount of data
> > > required per lu and per lun - It is of the order of 256 bytes per lu
> > > and 512 bytes (actually more like 350) per lun. The number of
> > > Luns/lus can be in the 10s of thousands.
> > >
> > > Even though the iSCSI PDU header carries a LUN number, this value
> > > is really transparent to the iSCSI layer. The iSCSI layer should
> > > not even know how many LUNs there are in the system. The size of
> > > the data set, and the cost of managing it are fairly significant.
> > > The ability of systems to dynamically add & delete LUNs/LUs should
> > > not be tied to the ability of the iSCSI layer to track the stats.
> > >
> > > I think reasons 1 & 2 are not very good reasons. An analogy would
> > > be asking TCP to perpetually keep statistics on every 4-tuple that
> > > was ever used to create a connection.
> > >
> > > I would recommend focusing on the error cases only for one - and
> > > perhaps have a table per error type tracking the last "n" errors.
> > > What does it matter if an R2T was received for a LUN or not? It
> > > just becomes a bunch of probably unneeded information to weed
> > > through to get to the real info.
> > >
> > > >
> > > > However, keeping statistics at this level does create some
> > work; perhaps
> > > > there is a way to make it optional.
> > > >
> > > > > In Section 5.9:
> > > > >    "The iscsiLUTable contains a list of iSCSI Logical Units that are
> > > > >    accessible via the iSCSI target."
> > > > >
> > > > > Would this list be the same as what the "Report LUNs" command
> > > > would give?
> > > >
> > > > It depends.  A LUN is just the address of a logical unit, and in the
> > > > general case, is only valid between a particular initiator and a
> > > > particular
> > > > target.  If a second initiator issues a "Report LUNs" to the
> > same target,
> > > > it may get back a different list if the target is performing
> > some sort of
> > > > LUN mapping.  Some targets will show the same set of LUNs
> > > > regardless of the
> > > > initiator; some won't.  There is no reliable way given the
> > current MIB to
> > > > find out what "Report LUNs" would return; this is probably
> > the domain of
> > > > a SCSI MIB.
> > > >
> > > > > In Section 5.7:
> > > > >    "The iscsiLunTable contains an entry for each known LUN
> > that is being
> > > > >    accessed using this session.  Note that is may not
> > contain all of the
> > > > >    LUNs that could be accessed; the only ones available to
> > iSCSI are the
> > > > >    ones that have been addressed specifically by iSCSI commands.
> > > > >    Therefore, LUNs that have been discovered via mechanisms
> > such as the
> > > > >    SCSI "report LUNs" will not appear in this table until they are
> > > > >    specifically addressed by the initiator.
> > > > >
> > > > > How long do these entries live in the table? If iSCSI sessions
> > > > logout and
> > > > > close, do these entries continue to remain?
> > > >
> > > > The current intent is to have entries live only as long as
> > the sessions;
> > > > these would be removed when the session is removed.  This is
> > the simplest
> > > > solution and would put the smallest burden on the implementation.
> > > >
> > > > However, we still have an open "requirements" question on
> > whether anyone
> > > > wants these to hang around longer.
> > > >
> > > > > Thanks,
> > > > >
> > > > > Venkat Rangan
> > > > > Rhapsody Networks Inc.
> > > > > http://www.rhapsodynetworks.com
> > > > >
> > > >
> > > > --
> > > > Mark A. Bakke
> > > > Cisco Systems
> > > > mbakke@cisco.com
> > > > 763.398.1054
> > >
> > > Somesh
> > >
> > > _________________________________________________________
> > > Do You Yahoo!?
> > > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054