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

[ronald lee <ronald.c.lee@sun.com>]

I hope everyone keeps in mind that applications have a timeout value.
Also, most host disk drivers today on Fibre Channel connection fails
an I/O within 3 minutes on a given path.  Most application timeouts
are longer like 7-15 minutes.  The wedge driver will attempt to try
on alternate path also so this must be included in meeting the 
application timeouts.


Y P Cheng wrote:
> 
> > From: Douglas Otis [mailto:dotis@sanlight.net]
> > Sent: Tuesday, October 31, 2000 11:03 AM
> >
> > It is not as simple as that.  StatRN does not provide a deterministic
> > timeout for a connection failure indication.  As such, it should not be
> > relied upon to determine a failed connection.  Even with
> > keepalive, the TCP
> > timeout will still be too long for useful connection recovery
> > should status
> > be pending.  It would be desirable to prevent a reset and overlapping
> > recoveries.  As such, for a connection failure detection to be useful, it
> > must be relatively quick.  The SCSI layer should know little about the
> > underlying transport so the transport must be pro-active in responding to
> > transport failure.  Repetitive probes every 10 seconds could satisfy
> > detection requirements while status is pending.  This would also
> > provide the
> > target early notice of a client failure as communication while not idle
> > would be deterministic.
> 
> You are 100% correct.  If we have a table defining all possible error, not
> receiving the PDU with the right StatRN is one.  The question becomes how
> long do you wait?  I also understand your position in using ping every 10
> seconds so we don't need to wait four minutes to decide if TCP connection is
> gone.