Subject: Re: iSCSI: NOP-Out closing the command window

From: "Julian Satran" <[email-masked]>
Date: Fri, 27 Jul 2001 19:19:28 +0300

Sandeep,

They are 3 distinguishing elements P and the ITT+TTT.

Julo

Sandeep Joshi <[email-masked]> on 27-07-2001 18:53:20

Please respond to Sandeep Joshi <[email-masked]>

To:   [email-masked]
cc:
Subject:  Re: iSCSI: NOP-Out closing the command window

If the NOP-Out does not have the ping-bit set, then it is a
ping response and *not* a new command being issued by the
initiator.

Hence, it seems that the NOP-OUT with P=0 need not carry a
new cmdSN (Mark's 2nd option).

Btw, I did not know the 2nd sequence (P=0 from initiator?)
below was valid
  > I->T NOP +P=0 +I=x+ Data
  > T->I NOP +P=0 +I=x

-Sandeep

Julian Satran wrote:
>
> Mark,
>
> Definitely a problem .  How about stating (the obvious) that NOP as any
> thing carying an ITT expectes an answer
> wheter it carries an echo (P=1) or not (P=0).
>
> If it does not carry an ITT it does not.
>
> We can have the following sequences all valid:
>
> I->T NOP +P=1 +I=x+ Data
> T->I NOP +P=0 + Data
>
> I->T NOP +P=0 +I=x+ Data
> T->I NOP +P=0 +I=x
>
> T->I NOP +P=1 +TTT
> I->T NOP +P=0 I=1 + TTT (no ITT)
>
> All would be permitted today if we remove the tie between ITT and P say
> that NOP must have an ITT if issued at initiators initiative.
>
> We might add as valid (today it is not, it is explicitly forbidden):
>
> T->I NOP +P=1 +TTT
> I->T NOP +P=1+ I= 1 TTT + ITT + Data
> T->I NOP +P=0  +ITT + Data
>
> The last requires us to "tweak" the termination rule (a target is
forbiden
> to answer a P=1 with a P=1
>
> comments?
> Julo
>
> Mark Bakke <[email-masked]> on 27-07-2001 16:25:20
>
> Please respond to Mark Bakke <[email-masked]>
>
> To:   IPS <[email-masked]>
> cc:
> Subject:  iSCSI: NOP-Out closing the command window
>
> When sending a NOP-Out without the P bit set, there's
> no response to update ExpCmdSN to keep the window open.
>
> On an otherwise idle session, sending a long enough
> sequence of these NOP-Outs can close the command window
> permanently.
>
> In case of a stuck command window, please break glass...
>
> The easy solution is to turn on the P bit, and get the
> responses to update the window, but that defaults the
> purpose of allowing the P bit to not be set in the first
> place.
>
> Another easy solution (but I almost hate to mention it)
> is not to have NOP-Out update the CmdSN.  This seems to
> have the possibility of breaking other things.
>
> I suppose we could come up with a more complicated rule,
> like "if the NOP-Out's CmdSN would be the last (or perhaps
> penultimate) CmdSN allowed by the current window, it MUST
> set the P bit."  Or something like that.
>
> Anyway, I see three possible solutions.  Any thoughts?
>
> --
> Mark A. Bakke
> Cisco Systems
> [email-masked]
> 763.398.1054

---

From: Sandeep Joshi <[email-masked]>
Date: Fri, 27 Jul 2001 13:34:32 -0400

> They are 3 distinguishing elements P and the ITT+TTT.

I believe you are commenting on my question about the validity
about the 2nd sequence.. correct ?  But this 2nd sequence isn't 
documented in Sec 2.12 or 2.13.

Incidentally, there is a similar ping type mentioned in Sec 2.13.1
and its used to test the connection from the target end.  Could 
you please say what the response would be :
  T->I  NOP +P=0 T=ff I=ff 
  I->T  < response or it none ? >

And I still prefer that the ping response from the initiator *not* 
have a valid ITT/cmdSN.  A 3-way ping looks forbidding and may open
up new problems.

-Sandeep