Subject: FW: iSCSI: PDU formats

From: Sanjay Goyal <[email-masked]>
Date: Wed, 12 Sep 2001 13:39:53 -0400

I agree with Robert.
 For the 3rd item, I would suggest we move T|C|0|CNxSG fields to byte 1 as
they are reserved in Login PDUs, and T-bit aligns with F-bit which is byte
1, bit-7. Anyway byte 1 is analyzed for different sort of bits in different
PDU formats.

Regards
Sanjay Goyal 

-----Original Message-----
From: Robert D. Russell [mailto:[email-masked]]
Sent: Wednesday, September 12, 2001 10:44 AM
To: Julian Satran
Cc: [email-masked]
Subject: RE: iSCSI: PDU formats

Julian:

I would like to request 3 small changes in the format of some of
the PDUs.  One of the design features that you have employed
very successfully to date is to have a given field, such as the
"Initiator Task Tag" for example, always appear in the same position
(bytes 16-19) in any PDU in which it appears.  This makes it easy
to understand, to implement, and to debug.  However, a few small
inconsistencies in the application of this design principle have
crept in with draft 7, and I would like to propose that we fix them.

1.  In draft 6 the SCSI Response PDU had one Status/Response field
	in byte 3 -- in draft 7-90 it now has a Status field in byte 2
	and a Response field in byte 3.  In draft 6 the Data-in PDU also
	had a Status field in byte 3, and in draft 7-90 it is still in
	byte 3, with byte 2 unused (reserved).  Would you please either:

	a.	Reorder the bytes in the SCSI Response PDU so that the
Status
		field will be in byte 3 (so it is consistent with the
Data-in
		PDU) and the Response field will be in byte 2; or

	b.	Move the status field in the Data-in PDU from byte 3 to byte
2
		(so it remains consistent with the SCSI Response PDU).

	I would prefer alternative a. because it would leave the Data-in
	PDU unchanged for drafts 6, 7 and 8, and the SCSI Response PDU
	has to change in any case.  However, obviously either solution
	would work.

2.	In draft 7-90, a field called "Response" appears in 3 PDUs:

	a.	In byte 36 of the Task Management Response PDU.
	b.	In byte 36 of the Logout Response PDU.
	c.	In byte 2 (if my request 1a above is taken) in the
		SCSI Response PDU.  This is clearly inconsistent with a and
b.

	Since bytes 2 and 3 are currently unused (reserved) in both
	the Task Management Response PDU and the Logout Response PDU,
	the simplest solution would be to move the "Response" field in
	those 2 PDUs to byte 2 in order to be consistent with the SCSI
	Response PDU.  To keep the design clean, the new "Qualifier" field
	in the Task Management Response PDU should probably also be
	moved to byte 3.

3.	In draft 7-90 the Login and Login Response PDUs have been modified
	with the introduction of the T, C, and CNxSG fields in byte 37.
	However, in the Login Response PDU these fields overlay the
	Status-Detail field, which is also in byte 37.  Although the way
	to interpret this field is uniquely determined by the context,
	it is context dependent and I believe that this will lead to a lot
	of needless errors in coding, and that it also makes debugging more
	difficult, because the use of this byte changes during the login
phase
	exchanges.  This means that you can't always look at it the same
way.
	To avoid this overlay, would you please move the new fields
	(T, C, and CNxSG) to one of the currently unused bytes.  Many bytes
	(2, 10-11, 20-23, 38-39, 40-47) are currently unused in both of
these
	PDUs, so there would appear to be no urgent need to overlay the new
	fields on top of an existing field in order to save space.

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 22 Sep 2001 08:06:58 +0300

it makes sense. Julo

                    Sanjay Goyal                                                          
                    <sanjay_goyal@iv       To:     "'Robert D. Russell'"                  
                    ivity.com>              <[email-masked]>, Julian                
                                            Satran/Haifa/IBM@IBMIL                        
                    22-09-01 01:49         cc:     Sanjay Goyal                           
                    Please respond          <[email-masked]>                    
                    to Sanjay Goyal        Subject:     RE: iSCSI: PDU formats            

Hi
 One more request for PDU formats.
 When we are aligning Response/Status bytes, why should we leave poor
Reason
byte alone in Reject PDUs. It also can be moved to Byte-2 of first word,
which is used for Response. IMO, Response is similar to the Reason of
Reject
PDUs.

Regards
Sanjay Goyal

-----Original Message-----
From: Robert D. Russell [mailto:[email-masked]]
Sent: Wednesday, September 12, 2001 10:44 AM
To: Julian Satran
Cc: [email-masked]
Subject: RE: iSCSI: PDU formats

Julian:

           b.        Move the status field in the Data-in PDU from byte 3
to byte
2
                     (so it remains consistent with the SCSI Response PDU).

           a.        In byte 36 of the Task Management Response PDU.
           b.        In byte 36 of the Logout Response PDU.
           c.        In byte 2 (if my request 1a above is taken) in the
                     SCSI Response PDU.  This is clearly inconsistent with
a and
b.

           Response PDU.  To keep the design clean, the new "Qualifier"
field

3.         In draft 7-90 the Login and Login Response PDUs have been
modified
           with the introduction of the T, C, and CNxSG fields in byte 37.
           However, in the Login Response PDU these fields overlay the
           Status-Detail field, which is also in byte 37.  Although the way
           to interpret this field is uniquely determined by the context,
           it is context dependent and I believe that this will lead to a
lot
           of needless errors in coding, and that it also makes debugging
more
           difficult, because the use of this byte changes during the login
phase
           exchanges.  This means that you can't always look at it the same
way.
           To avoid this overlay, would you please move the new fields
           (T, C, and CNxSG) to one of the currently unused bytes.  Many
bytes
           (2, 10-11, 20-23, 38-39, 40-47) are currently unused in both of
these
           PDUs, so there would appear to be no urgent need to overlay the
new
           fields on top of an existing field in order to save space.

Thanks,

Bob Russell
InterOperability Lab