Re: iSCSI - Change proposal Removing the X bit

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

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




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