Message-ID: <00ca01c35311$75485550$2f8b170f@rose.hp.com>
From: "Mallikarjun C." <cbm@rose.hp.com>
To: "Abhijit Lahiri" <abhijit_lahiri@yahoo.com>, <ips@ece.cmu.edu>
Cc: <supriyo_p2003@yahoo.com>
References: <20030724132910.17841.qmail@web41402.mail.yahoo.com>
Subject: Re: Clarification requested on iscsi-draft-20 w.r.t target behavior on error conditions
Date: Fri, 25 Jul 2003 18:00:07 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> We have noticed that in some error conditions, the
> iSCSI target neither sends any Reject PDU nor does it
> close connection. It drops the bad packet and logs an
> error message. Since in such cases there is no clue as
> to what the Device Under Test have gone through (I
> mean without viewing the log), do we say that the
> behaviour is incorrect ? 

Looking at the Reject reason code table in 10.17.1, I see
that sending a Reject PDU is required in almost all the cases 
(with the possible exception of "Immediate Command Reject",
since the target may not even have the resources to build
Reject PDUs when too many immediate commands keep
arriving).

For some of the Reject usages - such as rejecting a SNACK,
or payload digest error - the spec has been very explicit about
the mandatory requirement of Reject PDU response (check out
section 6).  We however are not that explicit about every reason
code - I do believe though that the intent is that it's required
to use Rejects except possibly for immediate commands (which
is only a best effort response).
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

----- Original Message ----- 
From: "Abhijit Lahiri" <abhijit_lahiri@yahoo.com>
To: "Mallikarjun C." <cbm@rose.hp.com>; <ips@ece.cmu.edu>
Cc: <supriyo_p2003@yahoo.com>
Sent: Thursday, July 24, 2003 6:29 AM
Subject: Re: Clarification requested on iscsi-draft-20 w.r.t target behavior on error conditions


> 
> 
> Hi Mallikarjun,
> 
> Thanks. Your direction was really useful.
> 
> We would request you to clarify another issue.
> 
> We have noticed that in some error conditions, the
> iSCSI target neither sends any Reject PDU nor does it
> close connection. It drops the bad packet and logs an
> error message. Since in such cases there is no clue as
> to what the Device Under Test have gone through (I
> mean without viewing the log), do we say that the
> behaviour is incorrect ? 
> 
> -Regards,
> Abhijit
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --- "Mallikarjun C." <cbm@rose.hp.com> wrote:
> > There is no hard rule involving connection drops and
> > Rejects.  
> > As I already said, the targets *may* drop the
> > connection when
> > the protocol error is disruptive enough to their
> > implementations.
> > In fact, either side may drop the connection at any
> > time (though
> > of course it will be very rare, one would hope) for
> > other reasons.  
> > Your protocol conformance tester would have to take
> > these 
> > factors into consideration.
> > 
> > > I wanted to know the effect of sequence errors
> > when
> > > ErrorRecoveryLevel=0.
> > 
> > A review of section 6 should help here. 
> > ErrorRecoveryLevel=0
> > means that session recovery is the only promised
> > level of recovery,
> > and PDU or connection recovery is definitely not
> > used.
> > It however does *not* mean that session recovery
> > must be used 
> > for every error (though it may be).  I'd in fact
> > expect that just the
> > specific task with the sequence error will be
> > terminated in all
> > cases (unless it's the initiator seeing a sequence
> > error with a status
> > PDU in ErrorRecoveryLevel=0).
> > 
> > Hope that helps.
> > --
> > Mallikarjun
> > 
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions
> > Hewlett-Packard MS 5668 
> > Roseville CA 95747
> > cbm@rose.hp.com
> > 
> > ----- Original Message ----- 
> > From: "Abhijit Lahiri" <abhijit_lahiri@yahoo.com>
> > To: "Mallikarjun C." <cbm@rose.hp.com>;
> > <ips@ece.cmu.edu>
> > Cc: <abhijit_lahiri@yahoo.com>;
> > <supriyo_p2003@yahoo.com>
> > Sent: Wednesday, June 25, 2003 7:09 AM
> > Subject: Re: Clarification requested on
> > iscsi-draft-20 w.r.t target behavior on error
> > conditions
> > 
> > 
> > > 
> > > Thanks for your clarifications....
> > > I have few more related questions. Please see
> > below.
> > > 
> > > > --
> > > > Mallikarjun
> > > > 
> > > > 
> > > > 
> > > > > Hi All,
> > > > > 
> > > > > We are in the process of desigining an iscsi
> > > > target
> > > > > simulator as per draft-ietf-ips-iscsi-20.txt. 
> > > > > 
> > > > > The draft does not seem to be explicit about
> > an
> > > > ISCSI
> > > > > target's behavior on encountering the
> > following
> > > > error
> > > > > conditions.
> > > > > 
> > > > > 1. Logout Request contains non zero
> > > > DataSegmentLength
> > > > > 
> > > > > 2. Write or Data-Out PDU contains data more
> > than 
> > > > >    MaxRecvDataSegmentLength
> > > > > 
> > > > > 3. When pre-negotiated KeyValue pairs (like
> > > > > InitialR2T, 
> > > > >    ImmediateData, DataPDUInOrder etc) are not
> > > > >    honoured in Full Feature Phase
> > > > >    ("not honouring", also means violation of
> > > > result 
> > > > >     function rules)
> > > > 
> > > > All the above seem to fall into the "protocol
> > error"
> > > > bucket,
> > > > so one would have to employ Rejects to deal with
> > > > these.
> > > > Depending on the severity of the impact on the
> > > > receiving 
> > > > implementation, it may also choose to drop the
> > > > connection 
> > > > in some cases. The protocol error discussion
> > text
> > > > (6.11)
> > > > provides a hint to this effect.
> > > 
> > > 
> > > Can we specifically say that an ISCSI Target
> > should
> > > always follow the following path :
> > > 
> > > 1. Send Reject
> > > 2. Then drop the conenction.
> > > 
> > > OR, should an ISCSI Target always drop the
> > connection
> > > ?
> > > 
> > > OR, can it send only reject and NOT close
> > connection ?
> > > 
> > > I am asking this because we are also developing an
> > > iSCSI protocol conformance tester from which we
> > will
> > > simulate these error conditions. 
> > > 
> > > If the draft specifies an well defined way of
> > > responding to the error message, the tester can be
> > > more specific.
> > > 
> > > If an iSCSI target is given the option of behaving
> > in
> > > any of the 3 ways specified above, the tester
> > needs to
> > > be prepared for any of the above cases.
> > > 
> > > > > 4. When the sequence of PDUs (DataSN for
> > Data-Out,
> > > > 
> > > > >    R2TSN for R2T, CmdSN for Command) are not
> > in 
> > > > >    increasing order
> > > > 
> > > > This protocol error manifests as a "sequence
> > error"
> > > > whose 
> > > > handling is described in fair detail in the
> > error
> > > > recovery chapter (section 6).
> > > 
> > > I am sorry about this query. I should have been
> > more
> > > specific  about this. 
> > > 
> > > I wanted to know the effect of sequence errors
> > when
> > > ErrorRecoveryLevel=0.
> > > 
> > > Which of the following might happen in this case
> > when
> > > errorRecoveryLevel = 0 ?
> > > 
> > > 1. Send Reject
> > > 2. Then drop the conenction.
> > > 
> > > OR, should an ISCSI Target always drop the
> > connection
> > > ?
> > > 
> > > OR, can it send only reject and NOT close
> > connection ?
> > > 
> > > > > 
> > > > > 5. SNACK PDU sent for an iSCSI PDU already 
> > > > >    acknowledged 
> > > > > 
> > > > > 6. If NOP-Out ping request is sent in response
> > to
> > > > a 
> > > > >    a NOP-In ping request
> > > > > 
> > > > > 7. Renegotiating KeyValue pairs which are not 
> > > > >    permitetd FFP,. (viz. MaxConnections)
> > > > 
> > > > These all seem to again fall into the protocol
> > error
> > > > category.
> > > > Note that #5 is specifically mentioned in the
> > Reject
> > > > reason
> > > > code table as a protocol error.
> > > 
> > > Right :)  Thanks.
> > > 
> > > 
> > > 
> > > __________________________________
> > 
> === message truncated ===
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>