iSCSI: connection recovery

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

some connection recovery issues and some misc stuff:

(1) SACK & expStatSN
--------------------
Assume a SACK has been sent for say (type=statSN,begin=5,len=5)
The target keeps sending more response PDUs (statSN=11,12,13..)
before it receives the SACK.  The initiator has held expStatSN
back at expStatSN=5 until it gets the missing statSN PDUs.

There is no pre-negotiated limit allowed between expStatSN and statSN.
See note at bottom of Sec 1.2.2.2.  "...a large difference at target
indicates a failed connection".

The lack of expStatSN increments will make the target think the
connection is bad and can cause termination.  This kind of defeats 
the purpose of connection recovery since the SACK was meant to prevent
connection failure in the first place.

So perhaps the statement above should say the target should continue 
with a large statSN difference when SACKs are outstanding ..? 

(2) Login-phase & connection recovery
-------------------------------------
There should be a statement indicating that only connections
in full-feature phase can be recovered.  It seems pointless
to hold target resources for recovering a connection on which
no SCSI (i.e.only iSCSI) activity occurred.   (e.g. LoginCmd/Response
was completed for the connection and TextCmd, etc negotiation was
in progress when the connection failed)

(3) Ping PDUs & tasks
---------------------
The NOP-Out & Nop-IN PDU have taskTag identifiers.  This means
the target & initiator have to hold resources for these ping
commands.  During connection recovery, some outdated Nop-In 
PDU will be resent just to clear out some outdated Nop-OUT task.
And vice-versa.

The purpose of NOPs is to test the connection or peer.  If you
get a ping, you would send an immediate response to avoid breaking
the connection.  If you get a "pong" (even for pings sent long ago), 
you *instantly* know the connection is fine. 

Unless I am missing some other purpose, the association of a ping
with an iSCSI task seems superfluous and could be removed.

(4) maxCmdSN limit
-------------------
Looking at Sec 7.1, the case where independent network adapters are 
handling individiaul connections for a session at the target.  

I dont see how the maxCmdSN value sent in response PDUs can be
incremented 
by independent network adapters, WITHOUT state sharing, to accurately
reflect the global&local resource capacity.  Who decides the next good 
value for maxCmdSN, and if it's ok across all boards ? 

This maxCmdSN value should really be replaced with something local 
and per-connection.  The initiator can then decide the appropriate
routing of commands.


Regards,
-Sandeep