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

[Stephen Bailey <steph@cs.uchicago.edu>]

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

The sad fact is, these are exactly the sorts of things that iSCSI is
going to break.  Specifically, these timeouts are based upon the
assumptions of transports used to date.

The application timeout must be at least the sum of:
  1) command queuing delay
  2) mechanism delay
  3) data transfer delay

In the case of iSCSI, the data transfer delay can be really difficult
to bound in a useful, static way.  The fact that SCSI operations can
represent huge individual data transfers, makes things even worse.
Network protocol designers would respond `duh, of course you need to
have adaptive timeouts, or chop the data transfers into smaller,
individually timed pieces (or both)'.  The SCSI upper layers aren't
really suited for this.

An iSCSI implementation could decide that a connection is too slow to
be useful and pull the plug, but then a traditional upper layer
recovery strategy would be to simply retry, and that's not going to
improve the situation.  Do you want the data transferred or not?

Simply stipulating that iSCSI must meet these application timeouts is
putting the cart before the horse.

Steph