Subject: RE: iSCSI-countdown to new version

From: "Julian Satran" <[email-masked]>
Date: Sun, 16 Sep 2001 12:49:49 +0300

Not for the session establishing login request.  Julo

"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]>
@ece.cmu.edu on 13-09-2001 20:33:30

Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
      <[email-masked]>

Sent by:  [email-masked]

To:   "[email-masked]'" <[email-masked]>,
      [email-masked]
cc:
Subject:  RE: iSCSI-countdown to new version

Hi Eddy,

The last part of the sentence was added just to highlight that if the first
full feature phase commands were immediate then it does not increment the
CmdSN.  I would therefore proprose:

  Command numbering starts with the login request on the first
  connection of a session (the leading login) and includes every
  non-immediate command issued afterwards including into the full
  feature phase.

The first login must be immediate otherwise if it is queued and there is a
missing PDU earlier in the command queue then the login will not get
processed.  If the login was for recovery we have stalemate!

Cheers

Matthew

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Thursday, September 13, 2001 6:25 PM
To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)'
Subject: RE: iSCSI-countdown to new version

I'm not a good writer but I would write it as:

  Command numbering starts with the login request on the first
  connection of a session (the leading login) and includes every
  non-immediate command issued afterwards.

The reason it works better is because all login commands have to be
immediate (with the correction you have stated).

BTW, I thought the reason for the very first login to have the I = 0 was so
hardware does not have to worry about the leading login and will just
always
advance CmdSN for the next Immediate command.

Does Julian know the leading login is supposed to also be Immediate?

Eddy

-----Original Message-----
From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
[mailto:[email-masked]]
Sent: Thursday, September 13, 2001 1:21 PM
To: [email-masked]'
Subject: RE: iSCSI-countdown to new version

Eddy,

I think I may be missing something here: what would you suggest the wording
to be?

Matthew

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Thursday, September 13, 2001 6:17 PM
To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)'
Subject: RE: iSCSI-countdown to new version

Because it says "afterwards whether during login".

Eddy

-----Original Message-----
From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
[mailto:[email-masked]]
Sent: Thursday, September 13, 2001 1:16 PM
To: [email-masked]'
Subject: RE: iSCSI-countdown to new version

Hi Eddy,

Why does 1.2.2.1 need modifying?

Matthew

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Thursday, September 13, 2001 6:13 PM
To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)'; [email-masked]
Cc: Sanjay Goyal; [email-masked]
Subject: RE: iSCSI-countdown to new version

So a correction is needed in 2.12.2.

Also, if all other login phase PDUs MUST be immediate, Section 1.2.2.1
needs
change because it clearly implies the opposite.

Eddy

-----Original Message-----
From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
[mailto:[email-masked]]
Sent: Thursday, September 13, 2001 12:41 PM
To: [email-masked]'
Subject: RE: iSCSI-countdown to new version

Hi Eddy,

IMO 2.12.2 is incorrect and the initial login command MUST be immediate as
are all other login phase PDUs.  Therefore 1.2.2.1 is correct.

Cheers

Matthew

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Thursday, September 13, 2001 5:15 PM
To: [email-masked]; [email-masked]
Subject: RE: iSCSI-countdown to new version

Section 1.2.2.1 says:

  Command numbering starts with the login request on the first
  connection of a session (the leading login) and includes every
non-immediate
  command issued afterwards whether during login or in full-feature
  phase.

But 2.12.2 says:

  Login MUST be issued as an immediate request (I=1) except for the
  first Login request (C=0) of the leading connection that MUST have
  I=0.

Since all commands during login must have the I bit set, I believe 1.2.2.1
3rd line should read

  command issued afterwards in full-feature

Am I correct?

Eddy

---

From: "Robert D. Russell" <[email-masked]>
Date: Tue, 18 Sep 2001 11:31:05 -0400

Julian:

Please see further comments below:

> Date: Sat, 15 Sep 2001 05:05:28 +0300
> From: Julian Satran <[email-masked]>
> To: Robert D. Russell <[email-masked]>
> 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
[email-masked]
603-862-3774

---

From: Santosh Rao <[email-masked]>
Date: Tue, 18 Sep 2001 09:14:07 -0700

Julian,

I agree with the proposal made by Bob Russell to seperate the (T, C, CNxSG) byte
field from the current overlay with the status detail. This overlay needlessly
complicates coding, structure layout and debugging. There are plenty of reserved
fields available that can be used, instead of having to overlay (T, C, CNxSG)
field with the status detail.

Using byte 1 in the login request & response PDUs seems a more natural fit since
that byte has been used for bit fields in all other PDUs [and was previously used
for the F bit in the login cmd/rsp PDUs].

Regards,
Santosh