RE: iSCSI: more on StatRN

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

Steph,

You should consider the problem of freeing resources on the target in a
predictable manner.  A TCP timeout will be a very long period to maintain
resources for a failed connection.  Without a deterministic means of
detecting a failed connection, an initiator that gives up on an adapter
frequently, may consume all available resources on the target within this
TCP failure detection period.  This TCP detection may be very long if
keep-alive is not recommended.  A SCSI ping could be used in a repeated
fashion to ensure a deterministic failure timeout during critical periods
within the ULP.  In the same manner of ensuring predictable behavior, a
global acknowledgement and no required connection allegiance is a good means
of ensuring resources are freed.  A 64 byte packet every 10 seconds is 51
bits per second steady state on the network.  Not much per connection but it
would also be a good reason to keep the number of connections within reason.
Keeping latency to a minimum would also require a minimum number of
connections be maintained or each connection becomes constricted by the
next.

Doug


> > 1. Hitting with the big hammer at the first error is a question
> of designer
> > judgement.  And he can do it whenever he wants - as long as we
> don't force
> > him to do it at the first error by mandating it.
>
> I don't agree.  Perhaps I have misinterpreted the experience of FCP,
> but it seemed that key interoperability problems in the early going
> were due to lack of specification of specific error (or, in some cases
> consistent) recovery procedures.  It becomes difficult to determine
> the exact nature of and who caused the problem if every implementation
> wanders into a different piece of nondeterministic space.
>
> The designer can judge that a work-around is necessary and deviate
> from the standard, but there should not specifically be latitude in
> the spec for designer judgement in the handling of detectable, illegal
> behavior.
>
> The trick is more in detecting the illegal behavior.  Again, the spec
> really should STILL not leave anything to chance in this regard.  It
> should spell out what should be detected and what should result from
> detection.  For example, the ST spec does this, in exhaustive detail.
> I imagine TCP's specification (such as it is) is fairly complete in
> this regard as well.
>
> This level of specification is the difference between a solid protocol
> on which an uninvolved parties can build hardware, and a protocol with
> a more specialized audience.
>
> > 3. I am aware of the pitfalls of keep alive - but it is a cheap way of
> > early detection of link failures, unless
> > you use the iSCSI ping (that is slightly more expensive).
>
> It's not cheap, and it doesn't seem necessary either.  Any network
> bandwidth you use is bandwidth wasted, and if you have quadratic
> connectivity, you have quadratic traffic.
>
> Note that I'm not saying that iSCSI ping, per se, is a bad idea, it's
> not.  What I'm objecting to is the use of periodic keep alives at
> either the TCP or iSCSI layer.
>
> Steph
>