Re: iSCSI: more on StatRN

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

> 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