Subject: RE: ISCSI: Error Recovery Level 0

From: [email-masked]
Date: Wed, 29 May 2002 16:11:21 -0600

But devices supporting level 0 are not allowed to attempt any of the other recovery methods.

It appears from reading the text for digest recovery, if a header disgest error occurs, that I just throw away the PDU. If the pduLength was corrupted, then I am now out of sync. Do I wait for the initiator to drop the connection?

The flow for a data PDU is simple enough.

So the error recovery, "incremental requirement description" is misleading.... no real data PDU transmissions are required. The target can just request logout.... Correct?

Kevin

-----Original Message-----
From: Mallikarjun C. [mailto:[email-masked]]
Sent: Wednesday, May 29, 2002 2:46 PM
To: [email-masked]
Subject: Re: ISCSI: Error Recovery Level 0 

Kevin,

From: "LEMAY,KEVIN (A-Roseville,ex1)" <[email-masked]>
> I have the following question on error Recovery level 0.
>
> On page 105, v12, it says that error recovery level 0 must perform Session recovery as described in 6.12.4.

I can't find it.

It's only saying that the minimally expected error recovery capabilities for level 0 are as described
in 6.12.4, not that session recovery must be performed for every error....

If you look in 6.12.4, it specifically states that session recovery is done only if all other recovery
attempts fail.

>
> This seems to imply that:
> If I have a multi-connection session were one connection experiences a digest error, then I must close all
connections on the session, even killing IOs over the good connection.
> This is absurd!

Indeed it would be if so implemented (even while it's legal).

>Why not just close the one connection that has a problem and allow the IO to be restarted on one of the other
live connections? There is nothing wrong with the session, only a single connection.

That's a reasonable recovery strategy (if it's a SCSI restart).
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
[email-masked]

>
> I guess I am calling for a level 0.5, so that I can abort only the troublesome connection. This would allow
for a much faster IO recovery without adding hardly any coding complexity that is required for level 1.
> Comments?
> Kevin Lemay

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 29 May 2002 16:28:04 -0700

From: <[email-masked]>

> But devices supporting level 0 are not allowed to attempt any of the other recovery methods.

It is absolutely acceptable for an iSCSI entity to drop a connection on seeing a digest error.
Regardless of the negotiated error recovery level, both entities must deal with TCP exceptions
as a fact of life - as the state diagrams show.

To reiterate, the ErrorRecoveryLevel key specifies what each side is promising to minimally support.
This promise provides the guarantee to the initiator to resort to a sophisticated error recovery.
Negotiation of 0 *does not* mean that the entities must drop session on every error.

>
> It appears from reading the text for digest recovery, if a header disgest error occurs, that I just throw
away the PDU. If the pduLength was corrupted, then I am now out of sync. Do I wait for the initiator to drop
the connection?

No, you (target) may drop on your own.  Please note that *connection recovery* (requires ErrorRecoveryLevel=2)
is different from a simple *connection drop* (any recovery level).

Please also refer to an earlier thread initiated by Ken Sandars on this topic a couple of weeks ago.
--
Mallikarjun

Mallikarjun Chadalapaka