Re: iSCSI: Towards a more effective PDU format

["Robert D. Russell" <rdr@mars.iol.unh.edu>]

Julo:

Of course you are correct that once the BHS is lost, you are out of synch
and have to drop the connection.  However, there is more to this issue,
and that is how quickly you can detect the failure and start recovery.

In both my proposal and the current WN Next-Qualifier scheme,
a PDU that is shortened due to loss of data can lead to a situation
where the receiver blocks waiting for the rest of the PDU to
arrive before it can be processed.  The only way to detect this
would seem to be to put timers on every read, so the read does
not block indefinitely.  When the timer goes off, the connection
has to be dropped.

However, in the WN Next-Qualifier scheme, the receiver can also block
in situations where data is simply corrupted but not dropped, which is
probably a more common situation.  This will NOT happen in my proposal.

For example, suppose there is a PDU consisting of a header with
some of the extensions (extended CDB and/or bidi-read), but no
data.  Further, suppose the length field in one of the WN items gets
corrupted, so that its value becomes longer than it should be and
points off the end of the header and all its extensions.  The receiver
cannot know that this length has been corrupted, since it has not yet
gotten to the data digest, and will therefore block on a read waiting
for the rest of that WN item to arrive, but it never will.

This cannot happen in my proposal, because the total length of the AHSs
part of the PDU is given as the AHS_length field in the fixed-length
BHS, and if that length field is corrupted then the data digest for
the BHS will immediately detect that.  It is true that the response
will be to drop the connection, but it happens right away, without
blocking on a read until a timeout occurs.  Similarly, if the
AHS_length field in the BHS is ok, but the length field in one of
the AHS items itself is corrupted, that will also be known immediately
in my proposal, because the data digest at the end of the AHSs part
of the PDU is checked BEFORE using any of the length fields in the
AHS items themselves.

This points out the weakness of the WN Next-Qualifier scheme --
that the receiver has to use unreliable data to decode the header
EVEN IF A DIGEST IS USED.  This NEVER happens in my proposal.

Thanks for your consideration,

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


On Tue, 13 Mar 2001 julian_satran@il.ibm.com wrote:

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