RE: iSCSI: DLB [T.31] ErrorRecoveryLevel 0.5

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

There is nothing in the draft explicitly forbidding the behavior you
suggest, but there is no intent to allow it.  You have no way of knowing
whether "using only a small portion of ERL 1" when ERL 0 was negotiated will
cause problems at the target end or not, since it's not a defined "feature"
and therefore may have unexpected consequences. IMO, it's bad behavior.  If
you've added code "to attempt to recover", just implement ERL 1.  If you
think there should be some interim level of error recovery between 0 and 1,
present a compelling argument for it and get it specified in the draft.
Otherwise your implementation is behaving in an undefined manner and IMO,
that's asking for trouble.  It all goes back to the "testing matrix" that's
defined by the features outlined in the draft - you are proposing that
there's an infinite testing matrix because it's ok to behave in a manner
that's not defined, as long as it's not forbidden?

Regards,
Marjorie

> -----Original Message-----
> From: Steve Reames [mailto:reames@diskdrive.com]
> Sent: Thursday, July 11, 2002 8:58 AM
> To: KRUEGER,MARJORIE (HP-Roseville,ex1); 'Black_David@emc.com';
> ips@ece.cmu.edu
> Subject: RE: iSCSI: DLB [T.31] ErrorRecoveryLevel 0.5
> 
> 
> Marjorie,
>          Let me explain my thoughts, and maybe you or the 
> list can tell me 
> if I'm way off base.
>          Suppose I'm an initiator, and both the target and I have 
> negotiated ErrorRecoveryLevel 0. If I lose an incoming PDU, 
> in theory I 
> should just log out. But maybe, for some simple cases, I've 
> added code to 
> attempt to recover. I take a guess that maybe the target also 
> can recover 
> from simple errors. I throw a SNACK at the target and attempt 
> to recover 
> the lost PDU.
>          There are two possible results: either it works, or 
> I get a Reject 
> PDU back from the target essentially saying it doesn't 
> support SNACK. In 
> the case of a Reject PDU, I log out, which is what I would have done 
> anyway, so I haven't lost anything. If I recover, then hooray!
>          What I'm hoping is that ErrrorRecoveryLevel 0 is not 
> supposed to 
> be interpreted as "not allowed to attempt recovery." My understanding 
> (which may be wrong) is that when the target declares 
> ErrorRecoveryLevel 0 
> it may or may not support error recovery for some simple 
> types of errors, 
> but if it declares ErrorRecoveryLevel 1, then it has 
> committed to me (the 
> initiator) that it will recover.
>          My original observation on David's comment [T.31] was that I 
> didn't want language that *forbids* the initiator from at 
> least making an 
> effort at error recovery, even at ErrorRecoverLevel 0.
> 
> Thanks,
> -Steve Reames
> --------------------------------------------------------------
> -------------
> At 05:13 PM 7/10/2002 -0700, KRUEGER,MARJORIE 
> (HP-Roseville,ex1) wrote:
> >David,
> >I don't understand what you are aquiescing to?  It seems to 
> me that what
> >Steve is proposing is a violation of the protocol - there is 
> no way to
> >negotiate "level 0 + SNACK", therefore as Mallikarjun pointed out, it
> >wouldn't work.  If you've negotiated error level 0, the 
> remote end of this
> >session won't support SNACK (or shouldn't).  This sort of 
> interpretation
> >would create an interoperability (not to mention testing) 
> nightmare - that's
> >why the error recover levels were defined in the first 
> place.  I think your
> >original comment is valid.
> >
> >Marjorie Krueger
> >Networked Storage Architecture
> >Networked Storage Solutions Org.
> >Hewlett-Packard
> >
> > > -----Original Message-----
> > > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > > Sent: Wednesday, July 10, 2002 12:57 AM
> > > To: reames@diskdrive.com; ips@ece.cmu.edu
> > > Subject: RE: iSCSI: DLB [T.31]
> > >
> > >
> > > Steve,
> > >
> > >> From DLB's comments:
> > >>
> > >>>[T.31] 9.16.1  Type
> > >>>
> > >>>   An iSCSI target that does not support recovery within 
> connection MAY
> > >>>   reject the status SNACK with a Reject PDU. If the 
> target supports
> > >>>   recovery within connection, it MAY reject the SNACK 
> after which it
> > >>>   MUST issue an Asynchronous Message PDU with an iSCSI 
> event that indi-
> > >>>   cates "Request Logout".
> > >>>
> > >>> This should be conditioned on the operational 
> ErrorRecoveryLevel of the
> > >>> session, not whether the target supports recovery 
> within connection.
> > >>
> > >> I would prefer that this not be conditioned on the 
> ErrorRecoveryLevel. If
> > >> I am writing code, I may choose to support 
> recovery-within-connection,
> >but
> > >> not all the features that would be required to move me up to
> > >> ErrorRecoveryLevel 1. I would like SNACK and Reject PDUs 
> to work properly
> >
> > >> for my code, even though it is technically only 
> "ErrorRecoveryLevel 0.5".
> > >> As I read it, changing the wording would allow the 
> target to ignore
> > >> my improved error recovery efforts unless I have a full
> >ErrorRecoveryLevel 1
> > >> implementation. David, I doubt that is what you 
> intended, so maybe you
> > >> want to word it a little differently.
> > >
> > > Actually, it was what I intended when I made that comment,
> > > BUT, I had not considered the scenario you describe above ...
> > > and so, I now agree with
> > > you.  Therefore I'll withdraw my [T.31] comment provided that the
> > > possibility of multiple "ErrorRecoveryLevel 0.5" levels 
> of support is
> > > described in the overview section to be added on error recovery.
> > >
> > > Thanks,
> > > --David
> > > ---------------------------------------------------
> > > David L. Black, Senior Technologist
> > > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > > +1 (508) 249-6449            FAX: +1 (508) 497-8018
> > > black_david@emc.com       Mobile: +1 (978) 394-7754
> > > ---------------------------------------------------
> > >
> 
>