SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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
    ---------------------------------------------------
    
    


Home

Last updated: Tue Sep 04 01:05:27 2001
6315 messages in chronological order