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

["Mallikarjun C." <cbm@rose.hp.com>]

Pat,

I think I understand your concern that Section 6.5 almost makes
it look as if PDU length can be ascertained on header digest errors
just as in other cases.

Your first formulation is closer to the level of detail I would prefer.
I'd however suggest text with a couple of tweaks.

"... MUST discard the PDU when its length can be reliably ascertained by other
means (such as the operation of a sync and steering layer), or close the connection."

This should leave enough room for other implementation options, while
pointing out the utility of the sync and steering layer defined in the spec in
this error scenario.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com


----- Original Message ----- 
From: <pat_thaler@agilent.com>
To: <Julian_Satran@il.ibm.com>; <pat_thaler@agilent.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, May 31, 2002 10:28 AM
Subject: RE: iSCSI-12-95: header digest error clarification


> Julian,
>  
> I'm not sure how explicit we have to be about the solution, but right now
> there is a MUST that isn't really achievable. It says one MUST discard the
> PDU but the implementation doesn't know what the PDU is. One possibility is:
>  
> ... MUST close the connection or attempt to find a valid header and discard
> everything from the bad header to the valid header.
>  
> or 
>  
> ... MUST attempt to discard the PDU. However, if the length field was
> corrupted, the boundary of the PDU is unclear. If the apparent header
> following the discarded PDU also has a digest error, the initiator/target
> MAY close the connection or attempt to find a valid header and discard
> everything from the bad header to the valid header.
>  
> This leaves the options open to the implementor but puts the MUST in terms
> of what can be accomplished. The only reason to get more explicit is concern
> about data corruption if a false valid header is found in looking for a good
> header, but that is extremely low probablility. 
>  
> Regards,
> Pat
>  
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Friday, May 31, 2002 4:43 AM
> 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@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
> 
> 
> 
>