Re: iSCSI: Towards a more effective PDU format

[julian_satran@il.ibm.com]

Bob,

Interesting.  This is close to one of the variants I had for IETF-50 (a
clear header).
The only adavantage it has is that you are able to read all the AHSs in one
read.
The (admitedly academic) disadvantage it has is that you are limited in the
size of extensions and have some redundancy.
The basic issue that was raised - and there is no simple way out - is that
once you have lost a block (BHS in your suggested layout) you are out of
synch.  There is no simple way around it (at least not one that can be
solved by changing layout) and an added digest (only the code or silicon to
account for it) is IMHO not warranted by what you gain.  If you are willing
to spend silicon or code on this the making header failures less probable
and recovering if you fail by dropping the connection is a better bet
(using the redundancy for a coding gain).  But this involves some
complexity too.

Julo

"Robert D. Russell" <rdr@mars.iol.unh.edu> on 12/03/2001 22:01:39

Please respond to "Robert D. Russell" <rdr@mars.iol.unh.edu>

To:   ips@ece.cmu.edu
cc:   bbrtrebia@mediaone.net, "Ashish P. Palekar"
      <ashishp@mars.iol.unh.edu>, Anshul Chadda <achadda@mars.iol.unh.edu>,
      Narendran Ganapathy <ng3@mars.iol.unh.edu>
Subject:  Re: iSCSI: Towards a more effective PDU format




All:

Here is a proposal for an iSCSI PDU format without WN Next-Qualifiers:

1. Every PDU must start with a 48-byte Basic Header Segment (BHS).
   Assuming header digests are in use, this BHS is immediately
   followed by a header digest that covers it.

2. Every BHS contains 2 fields at fixed locations:
   a) AHS-length, containing the total length of all Additional Header
      Segments (AHS) that follow.  This field is 0 if there are no
      AHSs.
   b) DATA-length, containing the total length of all Data that follows
      the AHSs.  This field is 0 if there is no data.

3. If the AHS-length field in the BHS is non-zero, all the AHSs
   immediately follow the header digest of the BHS.  An additional
   digest immediately follows that last AHS and covers all the AHSs.

4. If the DATA-length field in the BHS is non-zero, all the data
   immediately follows the AHS digest.  A data digest immediately
   follows the data.

5. If space within the BHS is an issue, the AHS-length field could
   be restricted to a single byte, and could be in units of 4-byte
   words.  This would allow up to 1020 bytes of AHSs to follow a
   BHS, and this seems to be more than enough for the uses foreseen
   (so far, only extended CDB and bidi-read info).

6. Each AHS should start with a word containing a TYPE field and a
   LENGTH field.  The TYPE field should be enumerated rather than
   bit-field encoded, for easier decoding and future expansion.
   The LENGTH field is the number of bytes of additional information
   in this AHS that follows this word.


Advantages of this proposal.

1. The receiver always knows where to find digests in a reliable manner,
   without having to use unreliable data to find them.

2. Because the BHS is fixed length, the receiver can reliably obtain the
   entire BHS and its header digest in a single "read" operation.

3. Because the receiver gets the AHS-length field from the BHS, it can
   reliably obtain the entire set of AHSs and the header digest covering
   them in a single "read" operation.

4. Because the receiver gets the DATA-length field from the BHS, it can
   reliably  obtain all the data and the data digest covering it
   in a single "read" operation.

5. Since each AHS begins with a word containing the TYPE and LENGTH in
   fixed positions, an unknown TYPE (i.e., a type introduced in the
   future that is received by a legacy receiver) does NOT result in
   loss of synchronization during header processing -- the receiver
   knows the length of this AHS in any case, and can just skip over it.


Disadvantages of this proposal.

1. A second header digest is required, but only if one or more AHSs are
   present.  In practice this should be a rare event.


Proposed iSCSI PDU Format


     +-------------+
     | 48-byte BHS |
     +-------------+
     | BHS digest  |
   --+-------------+--
     |    AHS 1    |\
     | - - - - - - | \
     |    AHS 2    |  \
     | - - - - - - |   > total length in AHS_length field in BHS
     |    . . .    |  /
     | - - - - - - | /
     |    AHS n    |/
     +-------------+
     | AHSs digest |
   --+-------------+--
     |             |\
     |    Data     | > total length in DATA_length field in BHS
     |             |/
     +-------------+
     | Data digest |
     +-------------+


Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774