RE: iSCSI ERT: data SACK/replay buffer/"semi-transport"

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

Steph,

I am aware of telco equipment that does not have any error checking between
interfaces.  I would not place a limit on capacity as a means of justifying
full reliance on TCP checksums.

Doug


> > Exactly, I've worked in this context (though its been some years now).
> > It was true (at one time) that tape had a tractability limit, e.g.,
> > a tape backup of a terabyte was out of the question.  Has that changed?
>
> I think this is precisely the point.  Existing, off-the-shelf SCSI
> solutions DO NOT presently solve this problem.  Both ||SCSI an FCP
> burp the operation on a expectable, O(days) failure rate.  The rate of
> adoption for the FCP-2 command recovery feature is overwhelming to the
> point that the tape guys have been talking about end-running the
> problem with explicitly addressed commands.
>
> What we have running iSCSI on TCP is such a drastic improvement in
> what you can expect from your SCSI service that we can eventually
> expect a disruptive change.  Trying to engineer it to the point where
> its 2^100 times more disruptive, when we don't really know where it's
> taking us in the first place is meaningless.
>
> [Warning: repetition ahead]
>
> TCP + link layer error detection is engineered precisely to ensure
> reliable data delivery.  It's clear from an engineering stand point
> that it is likely (not guaranteed, what is?) to do this quite well.
> In spite of much research, it seems like nobody here has come up with
> a strong indication that TCP + link layer error detection does NOT do
> its job well.  I do not think this is because nobody has ever looked
> at the problem.
>
> The lack of concrete information to support the case that TCP + link
> layer error detection is inadequate has us chasing our tails.
>
> Given the layer iSCSI occupies in the protocol layer cake, if we don't
> try to solve which is presently assigned to a lower layer, it seems
> quite comfortable to shim additional checks or recovery, or even
> a completely
> different transport substrate underneath if we do discover TCP + link
> layer error detection is not doing the trick, but it really seems like
> folly to engineer based upon an assumption that nobody has done a good
> job documenting.
>
> Steph
>
>