RE: iSCSI PDU Formats

["Robert D. Russell" <rdr@mars.iol.unh.edu>]

Julian:

Please see further comments below:

> Date: Sat, 15 Sep 2001 05:05:28 +0300
> From: Julian Satran <Julian_Satran@il.ibm.com>
> To: Robert D. Russell <rdr@mars.iol.unh.edu>
> Subject: RE: iSCSI: PDU formats
> 
> 
> 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.
> 
> +++ The fields  you are referring to are to be used only for status class 0
> they just detail the detail :-) and enable status to be maintained within
> the 2 bytes +++
> 

I would still argue that these bits are different than just "detailing the
detail", because in all cases when Status-Class is not zero, Status-Detail
is a numerical enumeration, not a set of independent bit fields each of which
has a separate interpretation.  Interpreting bits is a fundamentally different
way of looking at this field than as "just a number", and makes it impossible
to format a single "template" by which this PDU can always be viewed,
regardless of the meaning of the fields.  Such a template is extremely useful
in debugging and testing tools when there will be bugs (such as not using
a field or fields correctly), so that the interpretation of which overlay
to use may not be obvious or correct.  Not being able to define a single
template will needlessly complicate these tools and make them less useful.

There are other places in the standard where fields in a single PDU have
different meanings -- for example, the 4-byte field starting at byte 32 in
the Task Management Request PDU means either RefCmdSn or ExpDataSn,
depending on the task.  However, in all these other cases the format of the
field is always the same, usually a number, and thus can always be displayed
as such by a simple debugging tool.  This is the only place in the standard
that I am aware of where the different meanings require different formats and
is thus the only place where a single viewing template cannot be defined.

This is further exemplified by the fact that your diagram on page 87 of
draft 7-92 is the only one in the standard that has a 3-line overlay for a
field in a PDU.  I believe this diagram on page 87 succinctly illustrates
the problem people will have during debugging and coding.

As pointed out by Sanjay Goyal in his e-mail of 12-Sept, it would seem to
make more sense to move the (T, C, and CNxSG) fields to byte 1, which is
currently unused in both Login and Login Response PDUs, but which is
typically analyzed as different bit fields in many other PDUs.  If byte
1 is not acceptable, there are plenty of other unused bytes in both
the Login and Login Response PDUs that could be used -- I do not see
any benefit to "enable status to be maintained within the 2 bytes" if
doing so complicates the coding and debugging tasks.

It is already the case that fields in the Login Response, such as StatSn,
ExpCmdSN and MaxCmdSN, are valid only when Status-Class is 0, so if the
(T, C, and CNxSG) fields were moved to byte 1 (or some other byte) they
would also be valid only when Status-Class is 0, and in this case the only
acceptable value for Status-Detail would also be 0.

Thank you for your reconsideration,

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774