Re: iscsi: header digest issue

["Julian Satran" <Julian_Satran@il.ibm.com>]

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

pat_thaler@agilent.com Sent by: owner-ips@ece.cmu.edu 01-03-02 03:38

To:        ips@ece.cmu.edu         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