RE: Keep-alive traffic (was iSCSI: more on StatRN)

["Douglas Otis" <dotis@sanlight.net>]

Charles,

While inventing more servers and clients, SCSI transport must concern itself
with mundane issues of timeouts, flow control, and resource reservations.
The present specification does not allow any deterministic means of
detecting a communication failure, provide for flow control and the lack of
an explicit logout also does not aid a resource allocation effort (garbage
collection).  I am not sure what is accomplished by pinging before
disconnecting.  Rather than calling it ping, perhaps we should call the
function aloha, as it means both hello and goodbye. :)

Doug

> Hi:
>
> The scenario I had in mind was the minimalist one where a device, say in a
> storage utlity environment, wants to do garbage collection on iSCSI
> sessions.  In that case, the device might send some sort of iSCSI "ping"
> before it decides to preemptively close a dormant iSCSI session.  The sort
> of "ping" I had in mind would be subject to the same security checks that
> apply to any other iSCSI transaction.
>
> Is this rocket science? If so, I don't believe it's worth a whole lot of
> further discussion.
>
> Charles
>
> > Charles,
> >
> > You may wish to be less nebulous about when a probe would be used.  By
> > mandating probes when no communication is occurring while
> > status is pending
> > allows tight timeouts to enforced.  Three probes sent every
> > 10 seconds will
> > provide a connection failure at the point where a forth probe
> > would be sent
> > with still no acknowledgement as example.  During idle
> > periods, a keepalive
> > recommendation should be adequate.
> >
> > Doug
> >
> > > Hi:
> > >
> > > I assume the objection is only to mandatory keep alive.
> > >
> > > In high-availabilty scenarios, pinging of some sort goes on all
> > > the time to
> > > detect when an otherwise long-dormant node loses
> > connectivity or becomes
> > > brain-dead.
> > >
> > > I assume the issue is detection and cleanup of dead iSCSI
> > > sessions.  In that
> > > case, why not have the node issue a ping to a dormant
> > session when it has
> > > reason to believe that the session may be blown.
> > >
> > > Charles
> > > > -----Original Message-----
> > > > From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
> > > > Sent: Monday, October 30, 2000 3:25 PM
> > > > To: ips@ece.cmu.edu
> > > > Subject: Re: iSCSI: more on StatRN
> > > >
> > > >
> > > > > What probe rate on a waiting response without other
> > confirmation of
> > > > > connection happening would you specify?
> > > >
> > > > Upon further reflection I'm not sure I analyzed the situation
> > > > correctly.  I know you all think everything through
> > completely before
> > > > you start typing, so you can just stone me right now for
> > not doing the
> > > > same.
> > > >
> > > > I don't see why free running keep-alives are necessary at all in
> > > > iSCSI.
> > > >
> > > > Targets only care if the connection is lost when they are
> > returning
> > > > something to the initiator.  Attempting to send anything
> > from target
> > > > to initiator will detect a lost connection, so a keep-alive is not
> > > > necessary.
> > > >
> > > > Initiators will maintain task timers on outstanding SCSI
> > operations,
> > > > and when a task timer expires, whatever action the
> > initiator performs
> > > > (Abort Task exchange, ping, whatever) will discover the lost
> > > > connection.  Again, no keep-alive is necessary.
> > > >
> > > > Steph