Subject: Re: iscsi: header digest issue

From: "Julian Satran" <[email-masked]>
Date: Fri, 1 Mar 2002 10:40:30 +0200

Pat,

We discussed several alternative formats including a separate protection 
(parity) for the length fields.
All where dropped. The probability of an undetected error of length 1 in 
the header - using a CRC32 is 0 and holds at 0 for bursts up to 31 bits. 
On the total feasible header length (not very long) the probability is 
still far under the value you quoted (according to the draft we have 
submitted together yesterday :-)). I agree that the recovery logic becomes 
at bit more complicated if the digest is at an unknown position but the 
"goodput" is simpler and the "badput" is not critical.

In addition the logic for putting the header digest at a fixed position 
but including the AHS in the digest has the same flaw and the alternatives 
(include the AHS the data digest or provide a separated AHS digest) are 
not nice as they may (somewhat) complicate placement.

There are some radically different layouts - that may include a framer and 
lengths protected by CRCs and
and followed by Data+Header protected by a single CRC.  But we may want to 
leave those for iSCSI-2 :-)

Julo

[email-masked]
Sent by: [email-masked]
01-03-02 03:38

        To:     [email-masked]
        cc: 
        Subject:        iscsi: header digest issue

We have a concern about the header digest location in the PDU. Currently,
the header digest is located after the AHS. This is convenient for the
transmitter since it calculates the header digest over the BHS and AHS and
then appends the digest. 

The problem is that the receiver must read a field that is covered by the
header digest in order to know the position of the digest. This has two
problems: it reduces the hamming distance protection of the digest to one
and it can cause an error recovery problem when an error changes the 
length
field to a value that is beyond the end of the transmitted data stream.

The CRC generally has a hamming distance of 4 and we went to some effort 
to
pick a CRC that was robust in the presence of small numbers of bad bits.
With the current PDU definition, an error in the TotalAHSLength field will
cause the wrong value of the stream being read as the AHS. There is a
possibility that this location contains a value that is the same as the 
CRC
of the bytes up to that point. A single bit error has a 2^-32 chance of
producing an undetectable error.

The second concern is on error recovery when an error occurs in a PDU that
is not followed by other PDUs. The error may change the length field so 
that
it indicates a position beyond the end of the actual PDU. The receiver 
waits
for more data to arrive so that it can check the digest and then process 
the
packet. Since there is no more data arriving it will hang waiting until a
timeout occurs. Therefore, when this kind of error occurs the error 
recovery
doesn't function.

Both problems could be solved by placing the header digest after the BHS 
and
before the AHS headers. 

Regards,
Pat Thaler

---

From: Paul Koning <[email-masked]>
Date: Fri, 1 Mar 2002 12:07:05 -0500

> the header - using a CRC32 is 0 and holds at 0 for bursts up to 31 bits. 

That's a true statement for CRC-32 for the case where you've correctly
identified where the CRC field is in the data.

If you use the wrong value for the length (and therefore the wrong
value for the position of the CRC) then you have a 2^-32 probability
of accepting the header as valid.  

So the question becomes: how big a change to the header is needed to
make you look for the CRC field in the wrong place?  The answer is one
bit, because any one-bit change to the TotalAHSLength field does
that.  You might be able to make this less likely by using a rule that
only some TotalAHSLength values are valid, but that doesn't change the
outcome.  The values 0 and 2 are both legal, and these differ in only
one bit. 

So Pat is right: given the encoding chosen, the Hamming distance is
one.  

> ...
> but including the AHS in the digest has the same flaw.

That's true.  For example, if a single bit error changes the
TotalAHSLength from 0 to 2, even if you put the CRC in a fixed place,
you have just changed the bitstring it acts on by 64 bits.  That's
longer than the burst error limit of CRC-32, so there is a non-zero
probability of accepting such a damaged header as valid.  

> leave those for iSCSI-2 :-)

That one would work.  (It's how DDCMP was done...)  And I agree,
that's not a solution to be considered now.

       paul

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 29 Mar 2002 11:12:15 -0800

Paul,

One future solution could be SCTP-DDP and an IANA registration for SCSI.
Data transfers in the DDP_WITH_TAG mode where Placement Tag matches the CDB
tag.  The SCSI CDBs and responses use the ANONYMOUS mode where the tag
remains in the same position within the Data Chunk but interpreted by a
process associated with the Stream and not used for direct placement.  The
SCSI PDUs are contained within a Data Chunk and SCTP provides assured
structure-packet alignment with a fixed location of the CRC digest.

http://groups.yahoo.com/group/SCTP-DDP/files/

Doug

> > We discussed several alternative formats including a separate
> > protection (parity) for the length fields. All where dropped.
> > The probability of an undetected error of length 1 in the header
> > - using a CRC32 is 0 and holds at 0 for bursts up to 31 bits.
>
> > In addition the logic for putting the header digest at a fixed
> > position but including the AHS in the digest has the same flaw.
>
> > There are some radically different layouts - that may include a
> > framer and lengths protected by CRCs and followed by Data+Header
> > protected by a single CRC.  But we may want to leave those for
> > iSCSI-2 :-)
>