Re: iSCSI: NOP-Out closing the command window

["Julian Satran" <Julian_Satran@il.ibm.com>]

The target knows that the window is closed and so does the initiator. The
initiator may send only an answer (P= 0 + no ITT+ yes TTT). The ping is
answered and the connection is not broken (for a while :-)).

As a sumary the semantics and possible combinations - if we are to allow
only 2-way hanshakes - are:

I->T

ITT valid means "Initiator initiated Nop Exchange"
P=1 means "copy my data in your answer"
TTT valid means "answer in a target initiated Nop exchange"

The following combinations are correct:

ITT valid, P=0, TTT invalid
ITT valid, P=1, TTT invalid
ITT invalid, P=0, TTT valid/invalid

The following combination is incorrect:

ITT invalid, P=1, TTT valid/invalid
ITT valid, P=0/1, TTT valid



T->I

ITT valid means "answer in an initiator initiated NOP exchange"
TTT valid means "target initiated NOP exchange"
P=1 means "copy my data"

The following combinations are correct:

ITT valid, P=0, TTT invalid
ITT invalid, P=0, TTT valid/invalid
ITT invalid, P=1, TTT valid


The following combinations are incorrect:

ITT=valid, P=0/1, TTT valid
ITT=valid/invalid, P=1, TTT invalid

this allows for 2 way and 1 way nops.

Nops without an ITT will not carry CmdSN.

Comments?

Julo

Sandeep Joshi <sandeepj@research.bell-labs.com> on 29-07-2001 02:06:30

Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI: NOP-Out closing the command window





> The 3-way sequence is probably the simplest for the code to handle (no
> special path for a request that has no answer).

(I was almost going to drop the subject..but then) what
if the command window is *already* full when the target
sends the ping ?  If the initiator doesnt respond, the
connection will be broken.

Are we going to add a rule that the target must not send a
ping when the window is full ?  This wont work with all the
asynchrony (e.g. target sent a ping before the maxCmdSN limit
was hit at the target)

One should just turn around and send the ping response right
away, otherwise the other-end may timeout and take action on failure.
Treat pings as immediate commands.

Allowing pings to test the queuing sub-system are undoubtedly
noble ideas but these seldom make it (correctly) into practical
systems.

-sandeep


Julian Satran wrote:
>
> Sandeep,
>
> You are right the sequences are not documented now and that is why I put
> them out here - to hear comments.
>
> A PDU with P=0 from the target (no ITT) could be hadndled as a mistake.
>
> The 3-way sequence is probably the simplest for the code to handle (no
> special path for a request that has no answer).
>
> Julo
>
> Sandeep Joshi <sandeepj@research.bell-labs.com> on 27-07-2001 20:34:32
>
> Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> Subject:  Re: iSCSI: NOP-Out closing the command window
>
> Julian Satran wrote:
> >
> > Sandeep,
> >
> > They are 3 distinguishing elements P and the ITT+TTT.
> >
> > Julo
> >
>
> 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
>
> > Sandeep Joshi <sandeepj@research.bell-labs.com> on 27-07-2001 18:53:20
> >
> > Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
> >
> > To:   ips@ece.cmu.edu
> > 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 <mbakke@cisco.com> on 27-07-2001 16:25:20
> > >
> > > Please respond to Mark Bakke <mbakke@cisco.com>
> > >
> > > To:   IPS <ips@ece.cmu.edu>
> > > 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
> > > mbakke@cisco.com
> > > 763.398.1054