Re: iSCSI: Feeling a little peckish?

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

Ken, 

Here's my take on the usage expectations (where a
feature has implementation expectations, I commented below) - 

> TARGET's perspective:
> 
> SNACK type            ERL=0                        ERL>0
> ------------------------------------------------------------------
> status                      optional                      mandatory*
>                               (silently discard)

Correct.  But I'd suggest that the target *not* silently discard the
SNACK.  I propose that the Reject reason code be simply named
as "SNACK Reject" (i.e. drop "Data-").  The reason code was specific
about data because status SNACK support was mandatory way back,
and I suspect the description simply remained that way even now.

FYI, the only "silent" discard we had allowed in the past was on the
"premature SNACKs" (look at changelog b/n rev6 to rev7), but we 
then decided target should send back a reject even then (protocol error).

> 
> data/r2t                    optional                      mandatory
>                               (reject,
>                                reason=3)

More good reason to rename the reason code description - since
it could cover R2Ts as you point out, not just data.

> 
> data ACK                 optional                      optional
>                               (target never 
>                               sets the A bit)

I would call the first column as "must-not" than "optional".

> 
> 
> * Para 9.16.2 states that 'if the target supports recovery within connection, 
> it MAY discard the SNACK after which it MUST issue an Asynchronous Message 
> PDU with an iSCSI event that indicates "Request Logout"'.
> 
> Question: Is support for "recovery within connection" mandatory if the ERL 
> has been negotiated to be > 0?

Yes, look at section 6.13 - for the definition of "digest failure recovery".

> 
> 
> To complete the picture,
> 
> INITIATOR's perspective:
> 
> SNACK type            ERL=0                        ERL>0
> ------------------------------------------------------------------
> status                      optional                      mandatory**
>                                                                
> data/r2t                   optional                       mandatory**
> 
> data ACK                optional                       mandatory
>                             (can ignore the A bit)
> 
> 
> ** As the SNACK is sent by the initiator, it is up to it to decide whether to 
> do this, or to escalate recovery. Is this more of a SHOULD support than a 
> MUST, or am I missing something?

It is legally a "MUST-implement-MAY-use", if the initiator had promised ErrorRecoveryLevel > 0
in the negotiation.  Despite the promise, initiator ofcourse has the option to resort to a 
"bigger hammer" on *any* error.  So to summarize, targets may never really ascertain if
the initiator really has the SNACK capability, that was implied by "ErrorRecoveryLevel=1".
The negotiation of >0 really puts the onus on targets to meet the expectations.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com