iSCSI: Keep alive

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

Team,
Let me see if I can now boil down the thoughts that have occurred on the
keep-alive thread and some of my input:

It has been stated that there may be value in ensuring that a link has gone
down and re-establish it, without the SCSI application being aware.
Assuming that this is valid:

1. If for what ever reason an iSCSI session thinks something has gone wrong
and is contemplating dropping the connection it should Ping before dropping
a session that maybe down, as a possible confirmation that the link is
down.  (This is not 100% guarantee that this will always detect that the
connection is still active, but if responded too, that will guarantee that
the connection is still up.)
2. No point to pinging every 10 Seconds or so.  If nothing is outstanding,
or missing, then why Ping?  Perhaps the implementation can have time out
values  etc. that it can use to determine if a suspicious connection is
still up.  This seems to be an implementation issue.  I think that an
implementer note in the draft would be sufficient.  Something like "The
implementation may consider the discovery of dropped connections by use of
a Ping, at the point the implementation is suspicious of failure. (should
not be done regularly).  A suspicion maybe raised by an outstanding
expected response, beyond some Time-out value."
3. We do not need to find out if no one is home at the SCSI task layer,
that is the job of the SCSI Task layer.  We just need to ensure that the
iSCSI transport is OK.
4. It has been pointed out that, the ping can be returned by the HW,
without respect to things going on higher in the various layers, but that
with SW implementations, it may be blocked behind other unprocessed stuff.
This also depends on the implementation of the SW, and the buffer handling.
So I would suggest, that the very most a ping can help with, in the SW
implementation, is a premature line drop -- by the pinging side -- that
would have otherwise occurred without the ping.
5.The ping can be useful in sorting out the difference between a long SCSI
operation and a connection hang. That is, if it is a long SCSI response
time, the ping will return, and the connection dropping can be avoided.
6. The only time the adequacy of the above approach  is an issue, is when
stuff has backed up in the iSCSI buffers and SW TCP/IP buffers --
undelivered to SCSI -- for such a long time that  it is noticed on the
other end.  We have other flow control things to control this problem.
Therefore, a ping at (and only at) the time of suspicion and to avoid a
inappropriate connection drop is a valid approach.


.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403
Internet address: hufferd@us.ibm.com