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

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

it is already there - for a while - Julo

Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 06/13/2002 01:48 AM Please respond to Black_David

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

Catching up on email after vacation ...

This thread seems to have reached the right conclusion - it
might be worth adding a sentence instructing implementers not
to scan the incoming data stream for headers as the result can
be confused by (things that look like) headers in data if one
is not careful.  It's important to avoid being confused in this
fashion, but it's not easy.  An implementation that doesn't
get this right has no alternative but to close the connection
on a header digest error.

I bring this up here because I've been through the same issue
with the FCIP draft in great detail.  It is possible to tell
real headers from false headers by scanning far enough and
knowing what the maximum PDU size is - appendix D of the FCIP
draft contains an example of such an algorithm.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Friday, May 31, 2002 5:58 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,
> 
> 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
> > > 
> > > 
> > > 
> > > 
> > 
>