RE: iSCSI: PDU formats

["Ayman Ghanem" <aghanem@cisco.com>]

I agree with 1 and 2, but I still prefer to overlap Status-Detail with the
T/C/CNxSG in the same byte for the same reason behind changes 1 and 2. Both
fields provide login response status details, with meaning interpreted
differently based on the Status-Class.

-Ayman


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Robert D. Russell
> Sent: Wednesday, September 12, 2001 9:44 AM
> To: Julian Satran
> Cc: ips@ece.cmu.edu
> 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
> rdr@iol.unh.edu
> 603-862-3774
>
>