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

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

Pat,

From: <pat_thaler@agilent.com>
To: <cbm@rose.hp.com>; <pat_thaler@agilent.com>; <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, May 31, 2002 2:48 PM
Subject: RE: iSCSI-12-95: header digest error clarification


> Mallikarjun,
> 
> I like it, but it has the same problem I pointed out to Paul. Sync and steering
> (at least as in FIM and as in some of the other candidates) doesn't necessarily
> allow one to determine PDU length. What it does allow is identifing the start
> of a header (which may not be the next header after the bad PDU).
> 
> One could use:
> "... MUST either discard the header and all data up to the beginning of a later PDU 
> when that location can be ascertained by other means (such as the operation 
> of a sync and steering layer) or close the connection."

I see your point.  I like this text, but perhaps suggest "reliably" before "ascertained"
in the above.

Thanks.
--
Mallikarjun

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

> 
> or (to avoid a messy long sentence):
> "... MUST either discard the header and all data up to the beginning of a later PDU 
> or close the connection. Since the digest error indicates that the length field of the
> header may have been corrupted, the location of the beginning of a later PDU
> needs to be ascertained by other reliable means (such as the operation of a sync and 
> steering layer)"
> 
> 
> Pat
> 
> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Friday, May 31, 2002 12:39 PM
> To: pat_thaler@agilent.com; Julian_Satran@il.ibm.com
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI-12-95: header digest error clarification
> 
> 
> 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
> > 
> > 
> > 
> > 
>