RE: iSCSI-12-95: header digest error clarification

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

Pat,

I avoided being specific because an earlier format for headers that I suggested and that included separate parity for the length field got rejected
(too complex). and I felt that all the solutions that you mention are implementation options.
Do you think that we have to be explicit about them? 

Regards,
Julo

pat_thaler@agilent.com 05/31/2002 03:20 AM Please respond to pat_thaler

To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu         cc:                 Subject:        RE: iSCSI-12-95: header digest error clarification

Julian,

There was a brief discussion of the issues raised by header digest errors,
but nothing has made it into 6.5 Digest Errors. 

6.5 says that a target or initiator receiving a PDU with a header digest
error MUST silently discard the PDU.

The problem is that it can't do that. A header digest error means that
DataSegmentLength may have been corrupted so the receiver doesn't know
where the PDU ends and the next begins.

Possible resolutions:

If FIM is enabled, silently discard everything from the bad header to 
the next start of header pointed to by a marker.

If FIM is not enabled, chose one (or more of the following):
Assume that the DataSegmentLength is correct and check to see if a 
valid header including a valid header digest and CmdSN begins at the 
point indicated by the length. If it does, then drop the PDU as 
indicated by the DataSegmentLength and resume processing the next
PDU. If the next header doesn't check, close the connection or use the
next technique.
Downside: This entails a small risk that the DataSegmentLength was wrong
but unluckily pointed into a part of the data stream that looked
like a valid header. Also, there may not be a next header to check
immediately so one may have to wait for an indeterminate time before
closing this out.

Search the data stream for a valid header. This gets kind of ugly
because headers are 48 bytes long (or longer with AHS) but can start
every 4 bytes so one has check overlapping sets of bytes for a 
correct CRC which either means it will be slow or one will need 
multiple CRC checkers. Also, this has a significantly higher risk
of finding a false valid header. Therefore, this recovery method 
should not be allowed.

Close the connection.

Regards,
Pat 

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, May 29, 2002 3:02 PM
To: ips@ece.cmu.edu
Subject: iSCSI-12-95


12-95 is out.
It has the latest wording on security and text negotiation (including the
spanning).

Still to go - text fixes in chapter 11.

Julo