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

From: "Elliott, Robert" <[email-masked]>
Date: Wed, 27 Mar 2002 08:56:05 -0600

Comments below...

> -----Original Message-----
> From: Santosh Rao [mailto:[email-masked]]
> 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.

---

From: Santosh Rao <[email-masked]>
Date: Wed, 27 Mar 2002 19:05:29 -0800

Hello,

[ I changed the subject of this thread to be more meaningful to the
issue being discussed.]

Based on the below considerations, I am in favor of following the
example set by other serial scsi transports such as packetized SPI-x &
SRP, in not supporting CRN for iscsi.

Consider the following :

1) CRN is only defined as a parameter in SAM-2. Its usage semantics have
not been explained in SAM-2. It has also been made optional to support
for each scsi transport.

2) CRN usage description seems to have been left to each scsi transport,
based on the only usage being described in FCP-2, and not in SAM-2.

3) iscsi's CmdSN provides similar semantics as CRN, but at a session
granularity. (CmdSN usage, is mandatory, compared to an optional CRN.
CRN is on a per-lun basis. Cmdsn is 32-bit vs. 8-bit CRN.)

4) Due to mandatory use of CmdSN in iscsi, iscsi guarantees transport
ordering for command delivery and eliminates the need for yet another
sequencing scheme using CRN.
Other scsi transports that provide an ordered reliable transport do not
support CRN. The only scsi transport that supports CRN is FCP-2 and it
uses CRN to apply sequencing in a manner similar to iscsi using CmdSN.

Based on the above, I believe iscsi does not need to support CRN. 

Comments ?

Thanks,
Santosh

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03428.html

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################