Re: iSCSI - Change proposal Removing the X bit

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

Julian Satran wrote:
> 
> Sandeep,
> 
> I the scenario I have forwarded we C2 & C3 could have sent the  status on
> the pipe and the ExpStatSN carried in an immediate one-way nop.
> 
> Julo

Dont believe so..If that were the case, the retried C2 & C3 must be 
_ahead_ of that one-way NOP issued by the initiator, since the
initiator cannot see the status PDUs before retrying commands.

If the target cant read C2&C3 in the pipe, it cant see the
updated expStatSN either

-Sandeep


> 
> Sandeep Joshi <sandeepj@research.bell-labs.com>
> Sent by: owner-ips@ece.cmu.edu
> 26-10-01 23:46
> Please respond to Sandeep Joshi
> 
> 
>         To:     Julian Satran/Haifa/IBM@IBMIL
>         cc:     ips@ece.cmu.edu
>         Subject:        Re: iSCSI - Change proposal Removing the X bit
> 
> 
> 
> Julian
> 
> When would the initiator decide to issue the cleaning NOP ?
> Would this be done on a sequence wraparound ?
> My one concern is that this puts the onus of doing things
> correctly on the initiator, and the target susceptible to
> initiator bugs.
> 
> Here's an alternate idea..
> 
> It seems that for this scenario to occur the following
> condition must also be valid :
> 
>   A target MUST have a positive (expStatSN-statSN) for
>   connection c1 when it receives c2&c3 in a new window
>   on the same connection c1 - since the status acks
>   are pending in-order after the retried c2&c3.
> 
> If this is correct.. then would the following condition
> detect a connection which has gone stale ?
> 
>  A target MUST NOT allow a new CmdSN which is 2^31-1 greater
>  than the unacknowledged status PDU for the last cmdSN sent
>  on all connections.
> 
> This would involve maintaining an additional counter per
> connection.  (e.g. Connection->cmdSN_of_last_unacknowledged_statSN)
> 
> In other words, if connection C1 sent status PDU for (c3) which
> has not yet been acked thru expStatSN, then the target will not
> allow a new command (Cn) which is 2^31-1 greater than c3.
> This must hold for all connections.
> 
> This ensures that sequence wraparound does not cause old commands
> to reappear.  Either the connection is closed or the target
> issues a NOP-IN which flushes that connection.
> 
> If this is true, there is no need to issue the cleaning NOP
> since the target ensures that stale connections dont exist.
> 
> Note that currently, we have a very loose requirement Sec 2.2.2.2
>   "A large difference between StatSN and ExpStatSN may
>    indicate a failed connection."
> 
> If we can strengthen this condition, we can ensure that the target
> as well as the initiator detect the sequence wrap-around without
> relying on one end too much.
> 
> Comments ?
> 
> -Sandeep
> 
> Julian Satran wrote:
> >
> > Dear colleagues,
> >
> > We intend to publish very soon version 09 of the draft in its current
> > format (not many changes) and postpone the editorial changes (already
> under
> > way) for 10.
> >
> > One of the latest change proposal involves removing the X bit.
> >
> > The X bit has been used in several types of restart/replay but is
> somewhat
> > made redundant by the removal
> > of the command replay.
> >
> > This involves removing the X bit from request byte 0 and either making
> it
> > reserved or "shifting left" the rest of the general-use bits (I and the
> > direction bit).
> >
> > It also involves mandating a cleaning NOP.
> >
> > The cleaning NOP is needed in order to "flush out" old command PDU that
> can
> > be left over by simple sequences like the one in the following scenario:
> >
> > 2 connections
> >
> > On connection 1 I->T c1,c2,c3
> > On connection 2 I->T c4,c5,c6
> >
> > Targets receives everything and acts on commands but responses are
> sluggish
> > and initiators sees only an ack for
> > c1.  It then retransmits c2, and c3 while there answer are in flight
> back
> > after which the connection is almost dead and not used by initiator.
> >
> > After a complete wrap around, involving only connection 2,  the target
> > suddenly gets c2, c3 in a correct window and acts on them.
> >
> > The need to clean-up old PDUs is common to all protocols that use a
> > sequence that wraps and we suggested cleaning up using a NOP.  We will
> > mandate a cleaning NOP only on connections that had at least one
> "retry".
> >
> > It looks like we might e able also to abandon the task management -
> > reassign function and do it with a reissue (with the same NOP cleanout
> > implication) since retiring the replay function makes the reassign
> > unambiguous (reissuing a command, after logout, on a new connection -
> > implies reassign).
> >
> > Please comment - I need your input urgently.
> >
> > Julo