iSCSI:Keep-alive traffic

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

Folks,
With the Technical Coordinator hat on:

Please use the "iSCSI:" prefix, for iSCSI related things.

Hat off:

.
.
.
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


Charles Monia <cmonia@NishanSystems.com>@ece.cmu.edu on 10/30/2000 09:02:13
PM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE:Keep-alive traffic (was iSCSI: more on StatRN)



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
>