RE: [Fwd: iSCSI: items discussed at WG meeting]

["Elliott, Robert" <Robert.Elliott@compaq.com>]

Comments below...

> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Tuesday, March 26, 2002 7:50 PM
> To: IPS Reflector
> Subject: Re: [Fwd: iSCSI: items discussed at WG meeting]
> 
> "Elliott, Robert" wrote:
> > 
> > Don't assume that every new SCSI protocol will support CRN -
> > SRP does not, for one. 
> 
> From a reading of SAM-2, it appears that the "Send SCSI Command" and
> "SCSI Command Received" APIs (Section 5.4.2) define the CRN as one of
> the arguments, which seems to imply that scsi transports should be
> capable of transporting this argument, if the application 
> client decides to use it. (at least the newer scsi transports.)
> 
> Are you saying that this is not the case ? 

Yes.

> What is the basis for SRP not supporting CRN ? 

The description of CRN in SAM-2 mentions that protocols might not
support it - "It is not an error for the application client to 
provide this argument when CRN is not supported by the SCSI protocol 
or logical unit."

The same holds for autosense (although we did add language recently 
requiring all protocols except Parallel SCSI support autosense).

> What are the guidelines that determine whether a scsi transport should
> support CRN or not ? 

If the transport provides out of order delivery and you want to be able
to send queued commands to tapes, CRN may be helpful.

> If the CRN is not required to be supported by all scsi transports, is
> there a reason that iscsi needs to support this ?

Since iSCSI has added sequence numbers everywhere, CRN is not much of 
an extra burden.