RE: iSCSI: comments on rev 05

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

A few comments on general SCSI issues are embedded...

> -----Original Message-----
> From: Jeff Fellin [mailto:jkf@research.bell-labs.com]
> Sent: Friday, March 16, 2001 1:41 PM
> To: ips@ece.cmu.edu
> Subject: iSCSI: comments on rev 05
> ...
> Concern 6: Data transfer sizes
>    Since iSCSI is designed to work with the SCSI-3
>    specification. There is an inconsistency of data sizes with 
>    SCSI-3 WRITE(12)/READ(12) data transfer sizes. The WRITE(12) 
>    and READ(12) have a 32-bit length field that is in units 
>    of the device sector size, usually 512 bytes. This results 
>    in an maximum size in  bytes of 41 bits. Whereas, the
>    maximum size of a data transfer byte size in iSCSI is 32 
>    bits. How is iSCSI going to handle a SCSI-3 CDB requesting 
>    a data transfer size in bytes greater than 32 bits?

The initiator has to break up very long commands into multiple
commands to fit its protocol.  FCP-2 (SCSI over Fibre Channel) 
has a 32-bit DL field that imposes the same restriction.

> ...
> Concern 8: Section 2.18.2 Asynchronous Messages
>    The description of the various SCSI events in section 
>    2.18.2 appears to imply the iSCSI target has knowledge 
>    of events concerning the SCSI initiator on the target 
>    system, or perhaps that the iSCSI target actually
>    is the SCSI initiator on the target system. I believe this 
>    violates the concepts of transferring SCSI CDB's across a 
>    network into actually interpreting them, or having a strong 
>    interaction between the two protocol layers that doesn't 
>    appear in many other places.
> 
>    Why is there the need to have this type of interaction
>    between the clients of the iSCSI layer and the iSCSI layer?

Julian agreed to remove this.  The field will simply indicate
whether or not a SCSI Event exists.

> Concern 9: Section 3, Mode pages
>    I am not sure from reading the descriptions, but it sounds as if
>    the iSCSI target modifies the SCSI mode pages sent by it's SCSI
>    targets on return to the iSCSI initiator. This is due to 
>    the reference to the reference to the disconnect-reconnect mode 
>    page parameters in Section 1.2.5 and Section 3. Although I 
>    cannot find a SCSI document defining a Logical Unit Control 
>    Mode Page and Port Control Mode Page.
>  
>    Is this a reuse of a SCSI mode page name in iSCSI or 
>    actually the SCSI mode pages being modified by the iSCSI 
>    target? This appears to be similar
>    to the issue about SCSI events in Asynchronous Messages.

See SPC-2 revision 19:
	section 8.3.7 Disconnect-reconnect page (02h)
	section 8.3.10 Protocol specific LUN page (18h)
	section 8.3.11 Protocol specific port page (19h)

Page 19h was previously FCP-specific, but T10 redefined it as 
protocol specific and clarified that it affects the target 
port no matter which logical unit is being accessed.

Page 18h was added to hold protocol specific parameters that
can differ across logical units.

Page 02h has protocol related properties, too.

The device server providing these mode pages has to include
information from the iSCSI target stack.  SPC-2 includes 
this paragraph when describing page 02h: 
	"The device server communicates the parameter values 
	in this mode page to the service delivery subsystem.  
	Similarly the application client may also communicate 
	parameter values to the service delivery subsystem.
	This communication is internal to the initiator or 
	target device and is outside the scope of SCSI."

> ...
> Question 3: Section 1.2.5
>    The description about an initiator sending too much 
>    unsolicited data to a target mentions this is 
>    controlled by the FirstBurstSize parameter,
>    and is available from the disconnect-reconnect 
>    mode page. I don't see a iSCSI PDU that would allow 
>    an initiator to request this information. 
>    Is the assumption the iSCSI initiator would send a SCSI 
>    command to the iSCSI target to retrieve a SCSI mode 
>    page. This appears to violate the concept of packaging 
>    SCSI commands across a network, and instead actually
>    looking inside the SCSI command which should just be 
>    an opaque SCSI CDB and SCSI data responses.

iSCSI login can negotiate FirstBurstSize.  See iSCSI-05
page 110 in Appendix D, Login/Text Miscellaneous Keys.

If it supports this feature, an iSCSI initiator stack needs 
to track changes to the mode page value.  An application
client may choose to change the burst amount (within
bounds set by the logical unit) using MODE SELECT and 
MODE SENSE commands.  The iSCSI initiator stack either
has to snoop MODE SELECT and MODE SENSE commands, or require
the application client to use an API to set the FirstBurstSize 
used by the stack.  The application client would program this 
when it makes a change.  Only application clients that understand
the protocol should change these pages, so it's reasonable
to assume they can make special API calls to register their
changes.

A bridge between iSCSI and Fibre Channel might need to snoop
the MODE SELECT and MODE SENSE commands as they pass through
in each direction (possibly modifying data as it flows through)
so the values represent its own capabilities correctly.

> ...
> Question 14: Sections 2.5 and 2.6
>    Throughout the section I'm not sure what entities 
>    Initiator and Target refer to. Is it the actual SCSI 
>    initiator on the iSCSI initiator system
>    or the iSCSI initiator? Likewise for the term target.

I think "SCSI initiator" and "iSCSI initiator" are the
same.  An iSCSI initiator is a SCSI initiator that uses
iSCSI protocol.  The SAM-2 term "application client" might
be appropriate in some instances where initiator is used.
That might map to the "SCSI initiator" you have in mind.

> Comment 15: Section 2.6
>    It appears the information on <Target Cold Reset> and <Target Warm
>    Reset> is more appropriate in the paragraphs in section 2.5

I hope it will disappear altogether :-)

> Question 16: Section 2.6
>    The statement about the 'target MUST then close all of its TCP
>    connections' appears to imply the receipient of the task management
>    command is the iSCSI target.  Or must the iSCSI target examine the
>    information in the SAM2 remote procedure call to determine specific
>    actions on the iSCSI target's part?

A task management function is run by the "task manager" entity
described in SAM-2.  The task manager is part of the target
(target device).  It would have to communicate to the iSCSI target
stack software or hardware to make this happen.

> ...
> Question 30: Section 6
>    I am not sure what the term 'target' means in this 
>    section. Is it the iSCSI target implementation or the 
>    SCSI target devices attached to the iSCSI target system?

See my previous initiator comments.

---
Rob Elliott, Compaq Server Storage
Robert.Elliott@compaq.com