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

["John Hufferd" <hufferd@us.ibm.com>]

I agree that these are implementation options, in fact the use other then
FIMs is probabilistic in nature, and is inappropriate for this spec.  It is
however, the secret sauce that each vendor will do better then the others.
Two, deterministic ways, FIMs and connection restart, is sufficient for
this spec.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 05/31/2002 04:43:29 AM

Sent by:    owner-ips@ece.cmu.edu


To:    pat_thaler@agilent.com
cc:    ips@ece.cmu.edu
Subject:    RE: iSCSI-12-95: header digest error clarification




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@a                                                           
    gilent.com                  To:        Julian Satran/Haifa/IBM@IBMIL,  
                        ips@ece.cmu.edu                                    
    05/31/2002                  cc:                                        
    03:20 AM                    Subject:        RE: iSCSI-12-95: header    
    Please              digest error clarification                         
    respond to                                                             
    pat_thaler                                                             
                                                                           
                                                                           



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