SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Towards a more effective PDU format



    
    
    Barry,
    
    Thanks for outline.
    I will consider it as one of the variants I am going through to asses
    clarity.
    
    There are two things that are against it:
    
    1- several digests
    2- if I don't gather (how?) from BHS that TLVs are there then I have to do
    2 reads for each additional segment - and besides this you are using a
    field before knowing it is correct.
    
    We could however rearrange in any fashion the BHS and NWs to make it look
    very close to what you propose and still have one read per segment and data
    used only after checking.
    
    Regards,
    Julo
    
    "Barry Reinhold - Lamprey POP3" <bbr@lampreyNetworks.com> on 10/03/2001
    04:02:28
    
    Please respond to "Barry Reinhold - Lamprey POP3" <bbr@lampreyNetworks.com>
    
    To:   "ISCSI" <ips@ece.cmu.edu>
    cc:   "Robert Russell" <rdr@unh.edu>, "Ashish A. Palekar"
          <ashishp@iol.unh.edu>, "Jon Sreekanth" <jon.sreekanth@trebia.com>,
          "James Smart" <james.smart@trebia.com>
    Subject:  iSCSI: Towards a more effective PDU format
    
    
    
    
    All,
    
    I know there are well defined feelings about how a PDU should be
    structured,
    and not everyone is going to be in the same camp on this issue. However, I
    am concerned that the current PDU format with the WN field has not really
    achieved the goals that I, for one, would like to see it achieve. So, let
    me
    list a few objectives for the PDU format and then suggest one possible
    solution.
    
    Objectives for the iSCSI PDU (that could be improved upon).
    
    1. Simplicity - The PDU layout should be as straight forward as possible.
    Interoperability starts with simplicity. When the logical function is
    simple, documenting proper usage is a whole lot easier. When documentation
    is clear in a standard, the time to interoperability and market acceptance
    is reduced.
    
    2. Efficient operation in the common execution path. I think "rough
    consensus" can probably be achieved in terms of what parts of an iSCSI
    header are going to be needed in the normal flow and what parts are
    exception cases. If we have consensus on this we should be able to agree on
    where to make things easy and where to add complexity.
    
    3. Data integrity - If a header digest is going to be provided, the
    information it covers should be checked against the digest before being
    used.
    
    I think we can improve the current PDU format, in terms of these
    objectives,
    by doing the following:
    
    1. Providing a fixed size header that contains the most commonly used
    fields.
    2. Placing less commonly used fields in an optional portion of the header.
    3. Providing a header digest over the fixed portion of the header and a
    separate digest for the optional portion of the header.
    
    Basic approach:
    
    1. The fixed "BHS" portion of the header is in all iSCSI PDU headers. It is
    always the same size and is followed by a header digest that covers the
    "BHS", if header digests are being used. The fact that header digests are
    being used within a TCP byte stream is not encoded into the frame, but is
    obtained from state associated with the session. This allows the location
    of
    the header digest to be determined without using any information in the
    header. Only when the integrity of the header has been validated is the
    information in it used.
    
    2. The header contains information on the size of the complete PDU, and a
    length field for any additional headers. The integrity of this information
    has been validated as it is part of the "BHS". The location of the
    additional headers, if they exist (in most cases they will not) is after
    the
    header digest. Thus additional headers can be located using validated
    information.
    
    3. Each additional header is encoded using a standard TLV (type, length,
    value) format. In TLV format the fixed size type indicator tells how to
    interpret the data. The fixed size length field says how long the data is,
    and the variable sized value field contains the data. If an application
    doesn't understand the type, it can maintain sync. in the byte stream by
    skipping to the length field and then skipping the value.
    
    4. The complete set of TLV values are covered by a distinct digest. This
    digest is considered a part of the header digest in terms of iSCSI option
    negotiation but is physically distinct. Although this requires another
    digest calculation its usage is expected to be fairly low and it is most
    likely calculated over a small number of bytes.
    
    5. The data and data digest follow the TLV digest.
    
    In terms of layout, what you might have is the following:
    
    ================= Start of iSCSI PDU =============================
    
    
    
         This portion of the PDU contains the information in
         the "BHS" plus:
    
         1. The length field (4 bytes)
         2. The length of the TLV information
    
    --------------- End of the fixed size header ---------------------
    --------------- Start of the header digest (optional) ------------
    
    --------------- End of the header digest -------------------------
    --------------- Start of TLV information (optional) --------------
    
        (Additional header fields go here in a variable length space)
    
    
    --------------- End of TLV information ---------------------------
    ------ Start of "TLV header" digest (if header digest present)----
    
    --------------- End of "TLV header" digest -----------------------
    --------------- Start of data ------------------------------------
    
    
    
    
    --------------- End of data --------------------------------------
    --------------- Start of data digest (optional) ------------------
    
    =============== End of data digest and PDU =======================
    
    [David B: This looks better in a .pdf....are we allowed to use pdfs on this
    reflector?]
    
    I believe this to be a simple yet efficient structure for common usage.
    The optional headers require more involved processing, but allow
    incremental
    advancement of the TCP byte stream and avoids the loss of synchronization
    that might take place in other formats.
    The header can be verified, before being used.
    
    [Note 1: This PDU format does not attempt to address the problem of how to
    recover when there is a digest error. I believe this to be a distinct
    problem, though the PDU format could provide some additional level of
    robustness via redundancy of information at known locations.]
    
    [Note 2: Julian, If more detailed information on the PDU format is needed I
    would be glad to present it. However I think that most of the significant
    issues are addressed by this outline. The other items don't appear, to me,
    to be as significant.]
    
    Barry Reinhold
    Barry.Reinhold@trebia.com
    603-659-0885
    
    
    
    
    


Home

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