iSCSI: comments on rev 05

[Jeff Fellin <jkf@research.bell-labs.com>]

Julian,
I have several comments about revision 5. I have grouped them
into concerns, questions/comments, and editorial/grammar categories.

	Jeff Fellin
	fellin@lucent.com
	Member Technical Staff
	Lucent Technologies/Bell Laboratories
	600 Mountain Ave, Murray Hill NJ
	
	
	
	


====== Concerns ======
These concerns may be due to not comprending some of the mail on
the reflector, or lack of understanding the SAM2 specification.
If they really aren't issues with the specification please excuse
my naivete.


Concern 1: Login processing and PDU descriptions.

  The login processing descriptions and details are spread throughout
  the document, section 1.2.3 iSCSI Login, 1.2.4 Text Mode Negotiation,
  2.8 Text Command, 2.9 Text Response, 2.10 Login Command, 2.11 Login
  Response, and Section 4 Login Phase. As a result of this separation
  there are inconsistencies in statements about how login processing
  proceeds.  For example in Section 1.2.3 the statement is a login Response
  concludes the Login Phase. In Section 2.11, Login Response, the statement
  is made "The Login Response indicates the progress and/or end of
  the login phase".  The last paragraph of section 4 states the Login
  Response with the Final bit set to 1 can only be sent in response to
  a Login command or Text command with the F bit set to 1. Section 2.11.4
  until reading Section 4, it appears there is no way to send a Login
  Response with the Final bit set to 1, unless the iSCSI initiator sends
  a Login command with the Final bit set to 1. However, the iSCSI initiator
  can only send one Login command.  Section 4.1 states a Login Response
  indicating a rejection must have the F bit set to 1, but if it can only
  be sent when a Login or Text is received with an F bit set to 1, than
  this is a protocol error.

  The above statements could confuse an implementor reading the various
  sections. All the sections should be made consistent and/or provide pointers
  to the sections in the document where the other details are found.


Concern 2: Text mode negotiation
   The understanding of text mode negotiation is also complicated by being
   described in several places in the document: section 1.2.4 Text Mode
   Negotiation section 2.8 Text Command, 2.9 Text Response, and section
   4 Login Phase. For example in Section 1.2.4 the description states
   the initiator can provide a list that the target can select from.
   In Section 4.2 the initiator provides an ordered list where the target
   must select the first one it supports. This section also specifies that
   the target must select one of the list entries, although Section 1.2.4
   implies that not returning the keyword in a response results in
   selected the value "none" by omission.


Concern 3: Parameter Negotiation outside login
   There are several places in the document where the statement of text
   parameter negotiation outside the login phase occurs. Usually followed
   by a statement that this is after a login phase. My suggestion is to
   change the statements to be text negotiation after login phase. This
   occurs in Sections 4 and 5.

Concern 4: Text parameters
   There is no one place where all the possible text parameters are
   listed. One has to read the entire document to make sure they didn't
   miss any. It would be helpful for all the defined text parameters
   mentioned for login processing and security processing to be added
   to Appendix D changing the title to iSCSI Text parameter List.
	

Concern 5: Error/Exception procession
   It would be nice to have references to specific parts of Section 6
   when error processing concerns may arise. For example, referring to
   Section 6.1, in Section 2 when describing the values of reserved fields
   and undefined values.

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?

Concern 7: Text parameter negotiation
   Section 2.9.3 states that if the Text Response does not contain a
   requested key the initiator must assume the the target doesn't
   understand the key or the answer is 'none'. However, in section 4.2
   the statement concerning negotiation is the target MUST reply with
   the first option in the list. So, if the initiator doesn't provide
   a selection the target supports the target must pick an element from
   the list and cannot respond as section 2.9.3 states. The various
   sections should be revised to be more consistent, which I am willing
   to help with.

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?

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.





======= Comments/Questions ======

Question 1: Section 1.2.3 iSCSI processing.
   What is the value in sending an iSCSI command reject on a connection
   that isn't in the Full Feature Phase. Since the TCP connection is going
   to be terminated. Why not just terminate the TCP connection.

Question 2: Section 1.2.5
   I don't find any description of what an initiator is to do when it
   receives an R2T with is not valid, or requests data outside the command
   bounds.

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.

Comment 4: Section 1.2.5
   There is a statement "A target receiving data out of order SHOULD
   terminate the session." Since this is not mandatory, I expected to
   find something in Section 6 stating how an iSCSI target would deal with
   receiving data out or order. Otherwise I suggest changing this SHOULD to
   a MUST.

Comment 5: Section 1.2.8.2
   The statement is made the iSCSI considers the information it delivers
   as a contiguous stream of bytes. Although in Section 1.2.8.1 the
   description implies iSCSI deals with messages and has found a way to
   maintain message boundaries across the TCP bytestream. In addition 
   throughout the rest of the section it is mentioned iSCSI sends and
   receives PDU's (which are message oriented). Perhaps, I don't understand
   to what iSCSI is delivering a bytestream to in the Synch and Steering
   Model. It would be helpful to clarify where iSCSI delivers a bytestream
   or remove the statements concerning bytestream data.

Comment 6: Section 2.2
   The text refers to a 4-byte Next-Qualifier. However there is no
   description of 'Next-Qualifier'. It appears this 'Next-Qualifier' is
   a different name of the 'What's Next' field. I suggest replacing the
   term 'Next-Qualifier' with 'What's Next'. This also appears in section
   2.2.2.3

Question 7: Section 2.2.1
   The field description describes two bytes, although the orientation
   of the text doesn't make it clear. Request changing this to have
   a header for each byte, and make sure all text description for a bit(s)
   be indented past the bit position.

Question 8: Section 2.2.2.1
   I interpret the description of the AddCDB to be a multiplier of the
   expected number of additional CDB words to follow. Hence a value of
   zero would indicate no additional CDB words instead of 4 additional
   CDB words. Starting the addCBD at one allows determination of the
   additional header segment size by a simple shift. This could be considered
   a hardware type optimization.

Question 9: Section 2.2.2.3
   I'm confused as to which data length is ignored and which one is used
   by the description in this section. Is it the amount of data received
   or the length in a WN field, or something else?

Question 10: Section 2.3.1 and 2.3.5
   I'm not sure where the Length field referred in the description of b7
   is? I think the Expected Length is the value of 'Expected Data Transfer
   Length', but don't know where 'Length' field is?

Question 11: Section 2.4.1
   The layout of Byte 1 shows bits 5 and 6 has reserved with bit 7
   having the value of 1. In 2.4.1 it states bits 5-7 are reserved.
   Although the description in Section 2 would allow for reserved 
   fields to have a non-zero value, this could be missed in implementation.
   Request changing the description to say bits 5 and 6 are reserved, and
   stating bit 7 must have the value of 1.

Question 12: Section 2.4.2
   Why is there no successful iSCSI Response code in the Status/Response
   field?

Question 13: Section 2.5
   I'm not sure what service the Task Managment Command and Response are
   providing. Is it how a SCSI-3 application client requests the iSCSI
   layer to provide the task management remote procedure call as defined
   in Section 6.7 of the SAM2? If so, could you please state this in
   the beginning of Section 2.5. 

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.

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

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?

Comment 17: Section 2.6
   There is no description of the value in the Referenced Task Tag when
   the Response field has a value of zero. Since the field only appears
   to have a value when Response has a value of one(1).

Question 18: Section 2.10
   Should there be a section describing the value of the TSID?

Comment 19: Section 2.11.6
   The statement about TSID being the same on partial and final responses
   seems to fit better in section 2.11.5.

Comment 20: Section 2.12
   The description of the NOP-Out refers to a Ping Response. There is
   no such command. So Ping Response should be changed to 'NOP-In
   Response'. There is a reference to a Ping bit, but it isn't defined
   yet. the term should be replaced with the 'P bit'

Question 21: Section 2.12
   The statement is made that the initiator may conclude there is a problem
   with the connection if the NOP-in data is different than the NOP-Out data.
   It than describes what to do if the conclusion is made. If the
   initiator doesn't conclude a problem exists what would it do? Is there
   any insight from IP ICMP echo messages that could help with determining
   what an iSCSI initiator could do?

Comment 22: Section 2.12
   The last sentence about how an initiator sends a NOP-Out in response
   to a NOP-in is confusing to me. Suggest changing the sentence to:

	An initiator sends a NOP-Out when it receives a NOP-In with the
	P bit set, in which case the initiator copies the Target Tag from
	NOP-In and the P bit in the NOP-Out MUST be zero.

Comment 23: Section 2.16
   The description of AddRun in Section 2.16.2 and RunLength in Section
   2.16.4 appear to be inconsistent. Since a run is described by a
   starting sequence and a length, it appears the fields BegRun and
   RunLength describe such a sequence. I interpret the description of
   RunLength to be the number of additional runs missing. Is this really
   the definition or am I confused? 

Question 24: Section 2.17
   The statement is made that an initiator can chose to return only 
   a portion of a R2T request. What is the expection of how the iSCSI 
   target will handle this situation?

Question 25: Section 2.18.2
   The section states the 'Length parameter is set to the ...'. However
   there is no field in the message. Perhaps the 'Length parameter'
   should be named 'Parameter1 field'?

Question 26: Section 4.2
   There is a statement the 'security authenticates the user and the target'.
   Is the user in this situation the user of the iSCSI initiator or is
   it the iSCSI initiator?

Question 27: Section 4.2
   The first item in the list of negotiable security mechanisms refers
   to 'the host and target'. Is the host the iSCSI initiator or the user
   of the iSCSI initiator?

Question 28: Section 4.2
   The first item in the negotiation procedure mentions the options
   are listed in the initiator's reverse order of preference. This is
   a different type of list than described in section 1.2.4. To me this
   means the most preferred entry will appear last in the last. The
   second item states the iSCSI target selects the first item from the
   list it supports. Doesn't this always result in the least preferred
   item from the iSCSI target's perspective? Why would the negotiation
   automatically select the least preferred entry even if better 
   entries would exist?

Question 29: Section 4.3
   The statement is made a 'target MUST NOT send more than one Login
   Response with the F bit set to zero. However the description of
   Login Response, section 2.11, doesn't state this restriction, and
   implies more than one F bit set to zero could be sent. Why is this
   restriction necessary? And if it is necessary would it be possible to
   
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?

Question 31: Section 6.1
    If an iSCSI initiator receives a PDU with a format error. How does
    the iSCSI initiator determine an outstanding task for the PDU?
    The reason for this is I thought a session can have multiple tasks.
    If there are multiple tasks how does the iSCSI initiator determine
    which iSCSI target task to abort, since the task id information
    in the PDU cannot be relied on?
 



======= Editorial ======

Section 1.2.8.3
  First sentence: "We recognize that in many environments the following
  isa more..."    Change 'isa' to 'is a'.

Section 2.3.1
  The description of b7 (F). 'set to 1 when the immediate data that accompany
  the command are all' change to 'set to 1 when the immediate data that
  accompanies the comman is all'

Section 2.4.1
   This is the only description of bits in a byte numbered from b0 instead
   of b7. It should be changed to start with b7 to be consistent with
   the other PDU descriptions.

Section 2.7.5.
   Second paragraph, sentence stating 'if this bit is 1 the target MUST
   deliver packets'. The word deliver implies to me the target is guaran-
   teeing the initiator will get the packets in the exact order the
   target sends them. Given the many discussions about TCP dropping 
   packets and data arriving out of order, Perhaps the only constraint
   on the target is that it 'SEND' the packets in increasing buffer
   offset order, not 'DELIVER' the packets to the initiator after TCP
   and the Synch and steering layer process the packets.

Section 2.10.1
   Change 'CID does not change and this command is performs'
       to 'The CID does not change and the target performs'
        

Section 2.11.4
   Change 'the initiator may proceed to negote operational parameters'
       to 'the initiator may proceed to negotiate operational parameters'

Section 2.12
   Change 'duplicating the data that was provided in the NOP-Out'
       to 'duplicating the data provided in the NOP-Out'

Section 4.1
   List of how target can answer in the following ways, item 2.
   Change '... authentication mechanism and starts with the session
	   	immediately (enters full feature phase).'
       To '... authentication mechanism and immediately enters the 
		full feature phase.'

Section 4.2
    The first paragraph has:
    Change ' algorithms that were chosen in the negotiaton phase
		and is conducted by the text commands ...'
        To ' algorithms chosen in the login negotiaton phase
		 done by the text commands ...'