Subject: iSCSI: Next-Qualifiers and PDU diagrams

From: [email-masked]
Date: Fri, 2 Mar 2001 14:23:10 -0500

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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: [email-masked]
Date: Mon, 5 Mar 2001 09:01:04 -0500

> 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:	[email-masked] [SMTP:[email-masked]]
> Sent:	Saturday, March 03, 2001 12:03 PM
> To:	[email-masked]
> 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
> 
> [email-masked] on 02/03/2001 21:23:10
> 
> Please respond to [email-masked]
> 
> To:   [email-masked]
> cc:
> Subject:  iSCSI: Next-Qualifiers and PDU diagrams
> 
> 
> 
>

---

From: [email-masked]
Date: Tue, 6 Mar 2001 03:05:43 +0200

Sandeep,

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

Reagrds,
Julo

Sandeep Joshi <[email-masked]> on 05/03/2001 00:26:50

Please respond to Sandeep Joshi <[email-masked]>

To:   [email-masked]
cc:

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