Subject: iSCSI - Change proposal Removing the X bit

From: "Julian Satran" <[email-masked]>
Date: Fri, 26 Oct 2001 23:07:24 +0300

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

---

From: Sandeep Joshi <[email-masked]>
Date: Fri, 26 Oct 2001 17:46:36 -0400

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

---

From: "Robert D. Russell" <[email-masked]>
Date: Fri, 26 Oct 2001 19:33:04 -0400

Julian:

I vote for making the X bit reserved and leaving the I bit
and direction bits unchanged and unshifted.  This will cause
the least disruption to everything developed so far,
in our case, a lot of our testing software.
There seems to be no urgent need to "shift" the these other
bits, and there may be some future use for the unused X bit.

Thanks,
Bob Russell

---

From: Santosh Rao <[email-masked]>
Date: Fri, 26 Oct 2001 17:21:33 -0700

Julian,

In response to your below proposed changes :

1) I am in favor of your proposal to remove task re-assign and simply
re-issue the command on a new connection. 

2) Regarding the removal of X bit, I suggest that the bit be made
reserved and the position of the I bit and opcode be retained as is.

Thanks,
Santosh

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################