iSCSI: Out Of Sequence due to null sequence with multiple connections.

[Douglas Otis <dotis@sanlight.net>]

All,

Out of Sequence caused by multiple connections for iSCSI:

I attempted to discuss this issue at the IETF meetings but was tabled by
David Black for the Wednesday meeting.  At the beginning of the second
meeting, I was then told I should have attempted to discuss this issue at
the first meeting, and upon reminding him, I was then advised to take this
topic to the reflector.  So here it is and hopefully this will reach the
reflector. If this becomes repeated, my apologies.

Perhaps the inability of the iSCSI protocol to maintain sequence for
immediate commands is not considered important as was already mentioned, it
is seldom that it matters.  The point in time it is likely to matter however
is during these seldom events.  Should a command appear to hang and the
initiator attempts to bring the target into a known state, the likely method
per iSCSI would be to issue an immediate command that carries nulled
sequential information.  The management command could arrive before other
commands that it was attempting to cancel and as such fail to do so.  Rather
than bringing the target to a known state, the state becomes less known.

Solutions-
A) As suggested by David Black, deliver all messages to the target in
sequence and depend on the task attributes to sort out any problem.  This
would remove the use of the immediate command at the iSCSI level and thus
remove a need for the null CmdSN.

B) If the iSCSI sequencer is hung as a result of an unresolved hole in the
sequence or due to a resource limitation delivering to the target, use a
flag within transport to indicate the need for immediate processing but
assign CmdSN to the next sequential value.  Commands normally before the
immediate command pending a send to the target would then be rejected back
to the initiator to allow the initiator to resolve their status.

C) Place the immediate command on all connections and filter duplicates
based on the initiator tag.  From the duplicate packets, the relative
position of this management command could be deduced.

I favor B myself as it assures the acknowledgement of these immediate
commands as well as eliminates the need for sending duplicates.  David's
solutions assumes there will not be a need to deal with the iSCSI sequencer
in the event of a problem.  Sending commands back to the initiator by means
of rejection should allow a freeing of the iSCSI sequencer lock and ensures
the initiator can track the state of the target.  The present scheme does
not allow management nor provide for condition created by multiple
connections.

Doug