RE: iSCSI: Next-Qualifiers and PDU diagrams

["Venkat Rangan" <venkat@rhapsodynetworks.com>]

Julian,

Since you asked for other opinions... The parsing of the following PDU
structure:

WN-AHS1
BHS
WN-AHS2
AHS1
WN-AHS3
AHS2
WN-DATA
AHS3
Header-Digest
DATA
Data-Digest

requires the parse engine to "remember" the WN until the corresponding
header is parsed. This adds additional complexity to the state machine.

The alternative:

BHS
WN-AHS1
AHS1
WN-AHS2
AHS2
WN-AHS3
AHS3
WN-DATA
Header-Digest
DATA
Data-Digest

allows the parser to read the WN and the value and not have to carry around
the last-seen-WN while it reads the current value.

There is also some value in:

WN-DATA
BHS
WN-AHS1
AHS1
WN-AHS2
AHS2
WN-AHS3
AHS3
Header-Digest
DATA
Data-Digest

because the WN-DATA tells us whether there are digests. If you can also add
the overall length of all headers in WN-DATA, you can prepare and launch the
header digest while the header is being read. In parallel, you also know
where the Data is and whether a data digest is needed, so that can be
launched as well.

Regards,

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
julian_satran@il.ibm.com
Sent: Monday, March 05, 2001 4:34 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Next-Qualifiers and PDU diagrams




David,

It really does not matter where the TLV is - before or after the BHS or any
AHS.
What matters is that you read it always with the BHS (or any subsequent
AHS) and from it you derive what comes next.

The simplest structure is only a BHS (no data) and even there you need the
NQ to know that the data is not there.

On regular TLV the sequence of operations you do is:

Read TLV1
Read Variable part
Read TLV2

----


At best you can optimize it to:

Read TLV1
Read Variable+TLV2
Read Variable+TLV3

------

With our scheme - since we know that the first part BHS is always there we
can read

ReadBHS+TLV2
Readvariable+TLV3
-----------

There  is no TLV1!
I've put the NQ somewhat arbitrarily at the beginning - it could be at the
end - but that is  a matter of taste.

I could add it to the PDU descriptions as an opaque field so that you can
see your offsets at their final position (or almost final).

I would like as much as you to add clarity to the document without
affecting the structure of the header sequence (that is both efficient and
flexible) and if adding the field to the PDU description makes it easier to
understand then so be it - but let us hear some other voices too.

Black_David@emc.com on 05/03/2001 16:01:04

Please respond to Black_David@emc.com

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: Next-Qualifiers and PDU diagrams




> I will try to lessen confusion somehow - I am not sure that adding the NQ
> everywhere is the answer.

That'd be the most comprehensive thing to do, and I still think it's the
right
thing for clarity.  At an absolute minimum, using one convention for which
byte in a PDU is byte 0 is clearly called for.

> The trouble with TLV formats is that they need at least two passes.

I don't understand what you mean by "two passes", but see below
because it may not be an issue.

> With the NQ I use the fact that the basic header is always there
> and the qualifier will be needed do describe the next segment (its type
and length).

Requiring that the first TLV always be the basic header segment whose size
never changes is ok under a TLV approach.  The differences between what we
have now, and a TLV approach are:
(1) The information currently in the NQ before the BHS moves to the TL
     after the BHS.  It's still in a fixed location because the BHS is
fixed size.
(2) We spend another 4 bytes for the TL  to describe the BHS.  Now that
     I think about things a bit more, this initial TL could be omitted,
with
     the  TLV structure used only to describe what comes after the
BHS.
>From a parse standpoint, the first TL after the BHS can be parsed with
the BHS because that TL is always in the same place wrt the BHS.  Is
there a lot of value to having the TL for what comes after the BHS show up
on the wire before the BHS?  I'm sceptical.

Is there any good reason not to merge the two formats for describing
variable length segments?

--David

> -----Original Message-----
> From:   julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com]
> Sent:   Saturday, March 03, 2001 12:03 PM
> To:     ips@ece.cmu.edu
> Subject:     Re: iSCSI: Next-Qualifiers and PDU diagrams
>
>
>
> David,
>
> I will try to lessen confusion somehow - I am not sure that adding the NQ
> everywhere is the answer.
>
> The trouble with TLV formats is that they need at least two passes. With
> the NQ I use the fact that
> the basic header is always there and the qualifier will be needed do
> describe the next segment (its type and length).
>
> Julo
>
> Black_David@emc.com on 02/03/2001 21:23:10
>
> Please respond to Black_David@emc.com
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: Next-Qualifiers and PDU diagrams
>
>
>
>
> In working with some other folks, I stumbled across
> a format issue that's more confusing than it needs
> to be in the current iSCSI draft.  The issue is that
> Next-Qualifiers (WN, etc.) and the PDUs they go with
> are not documented/diagrammed together, making it
> hard to figure out how to parse iSCSI PDUs.
>
> For an example of how this causes confusion, consider
> the Text, Login and NOP PDU diagrams in Sections 2.8
> through 2.13.  Starting from one of these diagrams,
> how does one figure out the size of the Text or
> Ping data that's appended?
>
> The answer's not in the diagrams -- there's a 4-byte
> Next Qualifier preceding the PDU shown in each diagram.
> The Text or Ping data is considered to be a data
> segment, and hence the format of the Next Qualifier
> is that given in Section 2.2.2.3, including a 3-byte
> length field that answers the question.
>
> That's not an obvious answer, and there are several
> factors that contribute to it being potentially confusing:
> - None of the PDU diagrams show the Next-Qualifiers
> - Byte 0 means different things - at the top of
>      Section 2.2, it's the start of the Next-Qualifier,
>      but by Section 2.2.3, it's shifted down 4 bytes
>      to be the start of the Basic Header Segment.
> - Nothing obvious seems to say that the Text or the
>      Ping Data is a "data segment".  The latter
>      might be obvious, but the former isn't.
> - The Next-Qualifier structure is unexpected to
>      those familiar with other protocols.  A
>      common protocol structure is T/L/V (Type/
>      Length/Value).  Because the BHS type and
>      length are implicit, the iSCSI structure
>      is actually Type N+1/Length N+1/Value N.
> So, much as I realize the busy work involved in
> revising ASCII graphics, I think all the PDU diagrams
> in Section 2 need to be revised to show the Next-
> Qualifiers.  This would also take care of the second
> item above, because then byte 0 in all the PDU
> diagrams will be the first byte of the Next-Qualifier
> that precedes the Basic Header Segment.  Addressing
> the third item involves a few sentences in to
> explain what the "data segment" indicated by the
> Next Qualifier before the BHS actually covers/
> contains in those cases.
>
> The fourth item is a matter of taste.  It would
> certainly be cleaner if iSCSI used a TLV structure,
> rather than a T+1/L+1/V structure.  Much of the
> network community is familiar with TLV and will
> find the T+1/L+1/V structure confusing.  Are the
> 4 bytes saved by not having a descriptor for the
> BHS really worth it?
>
> On a related topic, it would be considerably
> cleaner if the type (WN) field were a single byte
> that was completely enumerated, rather than the
> current bit field structure, and if the
> peculiar convention for the AddCDB length in
> 2.2.2.1 were dropped in favor of the 3-byte
> length field in 2.2.2.3 to remove a case
> from the header parse logic.
>
> Mindful of my WG co-chair role, I really think
> the diagram revisions and explanations of what
> a "data segment" is need to be done.  OTOH,
> the above two paragraphs on whether to have a BHS
> descriptor and how to format the Next-Qualifiers
> are suggestions for further discussion.
>
> Thanks,
> --David
>
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>
>
>