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

From: [email-masked]
Date: Fri, 31 May 2002 11:28:13 -0600

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:[email-masked]]
Sent: Friday, May 31, 2002 4:43 AM
To: [email-masked]
Cc: [email-masked]
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 

	[email-masked] 

05/31/2002 03:20 AM 
Please respond to pat_thaler 

        To:        Julian Satran/Haifa/IBM@IBMIL, [email-masked] 
        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:[email-masked]]
Sent: Wednesday, May 29, 2002 3:02 PM
To: [email-masked]
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

---

From: Paul Koning <[email-masked]>
Date: Fri, 31 May 2002 14:28:52 -0400

>>>>> "pat" == pat thaler <[email-masked]> writes:

 pat> Julian, I'm not sure how explicit we have to be about the
 pat> solution, but right now there is a MUST that isn't really
 pat> achievable. It says one MUST discard the PDU but the
 pat> implementation doesn't know what the PDU is. One possibility is:
 
 pat> ... MUST close the connection or attempt to find a valid header
 pat> and discard everything from the bad header to the valid header.
 
 pat> or
 
 pat> ... MUST attempt to discard the PDU. However, if the length
 pat> field was corrupted, the boundary of the PDU is unclear. If the
 pat> apparent header following the discarded PDU also has a digest
 pat> error, the initiator/target MAY close the connection or attempt
 pat> to find a valid header and discard everything from the bad
 pat> header to the valid header.

How about a simpler statement:
    ... MUST either discard the PDU, if it can determine where the PDU
    ends, or close the connection.

    paul

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 31 May 2002 12:39:00 -0700

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
[email-masked]