Re: Clarification requested on iscsi-draft-20 w.r.t target behavior on error conditions

["Mallikarjun C." <cbm@rose.hp.com>]

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.
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>