Review feedback on draft-ietf-ips-iSCSI-02.txt

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

Julian/All,

Enclosed is some review feedback on  draft-ietf-ips-iSCSI-02.txt.

Thanks,
Santosh Rao
Reference : draft-ietf-ips-iSCSI-02.txt
========================================

o 	When command numbering is turned off (by setting InitCmdRN to 0), 
	what is the value of CmdRN to be used for commands ? 
	It would be preferrable to use a "don't care" value for the CmdRN 
	like 0xFFFFFFFF instead of using 0 which is intended to indicate 
	Immediate Delivery.

o 	Normally, command ordering is enforced by the layer above 
	SCSI (ex : file systems, volume managers, etc) and in such 
	cases command ordering should not be required.
	The spec iSCSI-02.txt states that "iSCSI initiators MUST implement the
	command/request numbering scheme if they support more than 1 connection
	per session" (Section 1.2.2.1). 
	Can the use of command numbering be made optional (using the existing
	mechanism of setting InitCmdRN to 0 during LOGIN) if the initiator 
	stack does not require command ordering, but has chosen to use 
	multiple connections per session ?

o	The reference to "Response Length" and "Response Data" in the SCSI
	Response PDU (Section 2.3) is unclear about Response Data. Does this
	refer to the same semantics as the Response Data used in Fibre
	Channel's FCP_RSP terminology ? 
	Where is the Response Data defined in the standard ? 

o	It would be desirable to have a set of error codes in the SCSI Response
	PDU that reflect any iSCSI PDU errors such as :
	- iSCSI cmd PDU fields invalid
	- Data Length different from desired length requested in R2T
	- Data Relative Offset different from buffer offset requested in R2T 
	...

o	A standard REJECT response would be highly desirable for all command 
	type PDUs (ex : LOGIN, LOGOUT, TEXT, NOP). 
	The REJECT response could include reason code and reason explanations
	which allow identification of the reasons for the REJECT.

o	Section 2.1.5 :
	"The initiator assigns a task tag to each SCSI task that it issues."
	The above should read ..."to each task that it issues", since initiator
	task tags are also used for non-scsi tasks like LOGIN, LOGOUT, NOP,
	TEXT, etc.

o	What are the "don't care" values to be used for ExpCmdRN and MaxCmdRN
	when command numbering is turned off ? Can this be explicitly specified
	in the draft ?

o	iSCSI should avoid interpreting Sense Data and creating/using any iSCSI
	specific check conditions, if possible. iSCSI specific errors should be
	returned in Response Data in the SCSI Response PDU (when the response
	data gets defined). THis allows for cleaner layering between SCSI and
	iSCSI.

o	The MaxCmdRN provides a form of dynamic queue depth management at the
	target end, which complements the standard SCSI Queue Full mechanisms. 
	However, turning off command numbering (as in the case of single 
	connection per session) also implies that this mechanism is un-usable.
	Any thoughts on some alternate schemes that would work even when using
	single connections per session ? (Could command numbering be turned on
	even for single connection sessions with a different meaning implying
	use for queue depth management only and not ordering ?)

o	Section 2.7. The Response field in the SCSI Task Management Response
	PDU could do with some enhancing. 	
	- The "No Task Found" response can be removed since the target should
	  not REJECT an Abort Task  received for a non-existent task. Targets
	  should respond with "Function Complete" for an Abort Task sent on a
	  completed task. This ensures that failure of Abort Task does not
	  trigger a higher level of error recovery from the initiator.

	- The following responses could be considered for addition to 
	  the list :
	  i) 	"No such LUN" when Abort Task Set, CLear Task Set or LUN Reset 
	  	is attempted on an invalid LUN.
	  ii) 	"Logical Busy" when a 2nd task management function is attempted
	  	while a prior conflicting task is in progress. 
		(ex: attempting LUN Reset while Target Reset is 
		 in progress, etc.)
	 iii)	"Function Not Supported" to allow targets to indicate no support
	 	for certain task management requests. (ex: target reset !).
		This should be treated differently from "Function Rejected"
		which could be used to indicate an invalid request.

o	It is still not clear as to why WRITE SCSI Data PDUs need to specify
	the LUN. (This is not done in the case of fibre channel.)

o	Section 2.12 only specifies version major and version minor. A Version
	High and Version Low would help initators and targets negotiate amongst 
	a range of versions. The major and minor versions can be made 4 bits in
	size, using the same length as is currently used for version major and
	version minor. (There have already been requests for this on the
	reflector).

o	Section 2.14. 
	The NOP Response PDU should allow a REJECT response for
	the NOP to deal with an invalid NOP command PDU. 

o 	Section 2.14. NOP Response PDU.
	"The target SHOULD also duplicate as much of the initiator ping data as
	allowed by a configurable target parameter".
	Is this referring to the PingMaxReplyLength login key ? If so, the
	initiator should not be sending more than this length in its NOP
	command PDU payload. Hence, the above could be re-worded to indicate
	that initators should honor PingMaxReplyLength and targets SHOULD
	duplicate all of the initiator ping data in their response.

o	Section 2.15.
	"The logout command is used by an initiator to 'clean up' the target
	end of a failing connection and enable recovery to start".

	This should be re-phrased since a logout can be used as a form of a
	graceful close of the I-T nexus.

o	Section 2.17.
	"The buffer offsets and lengths for consecutive PDUs should form a
	continuous range".

	Does the above imply targets are expected to request data in-order on
	R2Ts ? This is not a requirement for Fibre Channel currently. If this
	is not the intent, then, the above should be re-phrased to make this
	more clear.

o	Section 2.17.
	"The present document does not limit the number of outstanding data
	transfers". 
	This is not true, since MaxOutstandingR2T (as defined in Annexe C) is
	used to pre-negotiate the limit on the number of outstanding data
	transfers.

o	Section 2.17.
	"All outstanding R2T should have different target transfer tags". 
	Target transfer tags are used to track the state of the entire task 
	and should be the same value for all phases of that task.
	The ability to have multiple concurrent R2Ts seems to call for an
	additional qualifier for the task such as a task sub-id. Target
	firmware would typically use the target task tag to lookup a per I/O
	data structure that is tracking the state of that task. In order to
	track multiple outstanding R2Ts within the same task, a different field
	should be used. (something equivalent to a Sequence ID in Fibre Channel,
	if the target task tag were to be thought of as the RX_ID of fibre
	channel.)
begin:vcard 
n:Rao;Santosh 
tel;home:408-287-4856
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;-608
fn:Santosh Rao
end:vcard