Subject: Re: ISCSI: CmdSN in non-leading login

From: "Julian Satran" <[email-masked]>
Date: Tue, 14 May 2002 07:33:26 +0300

I guess you missed the point beyond the "immediate command" notion. Please 
re-read the Overview section. Julo

Bill Studenmund <[email-masked]>
05/13/2002 08:57 PM
Please respond to Bill Studenmund

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     John Hufferd/San Jose/IBM@IBMUS, <[email-masked]>, "Mark S. Edwards" 
<[email-masked]>, <[email-masked]>
        Subject:        Re: ISCSI: CmdSN in non-leading login

On Sun, 12 May 2002, Julian Satran wrote:

> John,
>
> My only point was that there is enough information in the section to
> describe correct behavior.

> And immediate commands do not create any blockage regardless of their
> CmdSN.

Don't they though? Say I have a queue depth of 2, and I start a secondary
login with a CmdSN of 1000. I can then send other immediate commands at
1000, and a non-immediate command at 1000. I can then also send a
non-immeidate command at 1001. But can I send a command at 1002 before the
login has finished? If we increase the queue depth, there will still be
some other command number that would overflow it.

Say the login takes a while. Won't the login pin the queue at 1002 until
it's done? Now let the login take a while, it requires talking to say a
low kerberos server or doing a DH computation. If we really pay attention
to CmdSN, then the slow login process can effectively take the device
off-line while it completes, since we can't enqueue new commands.

Worse yet, say the secondary connection is NOT from our initiator, but
from an imposter. All the rogue has to do is get the TSIH right & guess a
CmdSN, and stall at trying to add another connection. Say do leading
negotiation, but just never send any security negotiations. The queue will
eventually become pinned until the target times out. Nice little DOS
attack; all you have to do is get the TSIH right & guess a CmdSN. You
don't have to do any security negotiation.  :-)

I'd like to suggest that we just ignore CmdSN on non-leading sessions,
beyond the fact that a well-behaved initiator should pick a CmdSN in its
current command window. We certainly shouldn't pay attention to it before
security negotiations have completed. :-) Oh also no commands should be
sent over the new connection with a CmdSN lower than the one used in the
new connection.

Take care,

Bill

---

From: Ken Sandars <[email-masked]>
Date: Tue, 14 May 2002 18:03:00 +0000

Hi Julo,

I'm looking to confirm the SNACK requirements from a target's perspective for 
each negotiated ErrorRecoveryLevel. Can you (or any other error handling 
expert - Mallikarjun?) confirm I captured the gist please?

TARGET's perspective:

SNACK type            ERL=0                        ERL>0
------------------------------------------------------------------
status                      optional                      mandatory*
                              (silently discard)

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

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

* 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?

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?

Cheers,
Ken

Ken Sandars
Eurologic Systems, Ltd
[email-masked]

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 15 May 2002 12:43:24 -0700

Ken, 

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

> SNACK type            ERL=0                        ERL>0

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

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

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

> has been negotiated to be > 0?

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

> SNACK type            ERL=0                        ERL>0

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
[email-masked]