RE: iSCSI MIB Object Model

["Somesh Gupta" <someshg@yahoo.com>]

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