Re: iscsi: CRN support not required. [was :Re: [Fwd: iSCSI: itemsdiscussed at WG meeting]]

[Santosh Rao <santoshr@cup.hp.com>]

Robert Grant wrote:

> 
> If you accept that making FC and iSCSI work well is not just the work of the
> fabric devices (dare I call them "boxes in the middle"?) then where is the
> best place to deal with the CRN mode pages? Does having the bridge deal with
> this make sense? 

A bridge will have to intercept, interpret and map protocol specific
mode pages from 1 protocol domain to another. The simple reason for this
being that the protocol specific mode page content differs based on the
protocol and hence, the bridge will need to build its own protocol
specific mode page and perform a mode sense/select with the back-end
device.


> It strikes me that CRN is a function between the initiator
> and target and as such is best left (as near as can be obtained) as
> negotiated between the two. So Dave's suggestion of iSCSI mode pages makes
> the most sense to me.

To be more precise, SAM-2 defines CRN as being originated by the
application client and destined to the device server. Hence, the
conclusion one draws from this is that the CRN should belong to the SCSI
ULP peer layers. While it is true that FCP-2 has not maintained that
layering, it would be good to attempt to fix that and move all CRN text
to SAM-3 and negotiate CRN in a protocol independent mode page.

 
> Also - and this is as much a question as a statement because I honestly
> don't know - but are there other aspects of mode pages where having iSCSI
> mode pages is the best answer?

Mode pages have a number of issues with respect to the scope of the mode
page implementation at the target (shared mode page implementations are
the common implementation, leading to mode page war situations when
multiple initiators [say, different drivers], attempt to set different
mode page values). In addition, mode page negotiations result in
parameter rounding situations and it is quite cumbersome/inefficient for
the initiator to then detect what the mode page value was set to.

It is time we looked at more modern ways of negotiating scsi transport
specific parameters than mode pages.


> For example, will the use of confirmed
> completions never make sense in an iSCSI environment? If there's ever a use
> for confirmed completions, then the setting of the equivalent to REC_TOV in
> an iSCSI mode page might make sense, too.

iscsi already defines the concept of command retry, task re-assign, data
sequence numbers, status sequence numbers and target originated NOP-IN
to solicit an ExpStatSN update. All of these result in more powerful
recovery schemes than the ones being referred from the FCP-2 protocol.

> So Dave's suggestion of adding a
> mode page can also be viewed as a more general solution than just addressing
> CRN.
> 
> Regards,
> Rob
> 
> Rob Grant
> McDATA Corporation
> 
> > -----Original Message-----
> > From: Paul Koning [mailto:ni1d@arrl.net]
> > Sent: Monday, April 01, 2002 2:15 PM
> > To: dap@cisco.com
> > Cc: ips@ece.cmu.edu
> > Subject: RE: iscsi: CRN support not required. [was :Re: [Fwd: iSCSI:
> > items discussed at WG meeting]]
> >
> >
> > I find it interesting that SAM-2 mentions CRN but doesn't seem to give
> > it any semantics, leaving it to one particular transport to choose
> > semantics that it likes.
> >
> > If the semantics are transport-specific, then cross-transport bridges
> > will have to be prepared to do appropriate work to handle what each
> > side expects.
> >
> > From what I can see, minimally iSCSI could omit the CRN entirely,
> > since it is not necessary in iSCSI.  It currently carries it without
> > specifying any use for it.  (I believe this is the point that Santosh
> > made.)  Perhaps the intent was for it to be carried to iSCSI/FC
> > bridges so those bridges can just pass it on, rather than having to
> > make one up locally?  If so, that seems innocuous, but would be worth
> > stating explicitly.
> >
> > I'm puzzled about what else iSCSI could do.  We could invent semantics
> > for this currently-unneeded thing, but to what purpose?  As for
> > protocol specific LUN modepages, I thought that iSCSI doesn't have any
> > protocol specific modepages.  It seems a stretch to add a whole new
> > mechanism (modepages) to iSCSI solely in order to say something about
> > a field that iSCSI isn't even using.
> >
> >     paul
> >

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################