Re: iSCSI: Next-Qualifiers and PDU diagrams

[julian_satran@il.ibm.com]

Sandeep,

The Length field is there - it is part of the NQ.

Reagrds,
Julo

Sandeep Joshi <sandeepj@research.bell-labs.com> on 05/03/2001 00:26:50

Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>

To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: Next-Qualifiers and PDU diagrams





Julian,

One suggestion.  Perhaps, it may ease the confusion if the draft
mentioned that iSCSI headers have been modelled analogous to the
IPv6 header formats.  (..confusions lessen when examples abound)

The IPv6 basic header and every extension header has a "next header"
segment field (T+1/L/V), and it seems to help in IPv6 routing
  - no varlength basic headers
  - no need to examine extension headers, etc

On the other hand, as suggested earlier by someone, a payload
length field in the BHS would ease data placement.

-Sandeep

julian_satran@il.ibm.com wrote:
>
> 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
> ---------------------------------------------------