SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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
    


Home

Last updated: Tue Sep 04 01:04:10 2001
6315 messages in chronological order