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

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

> The Stone and Partridge paper is mostly not applicable to an iSCSI
> environment.  The principal failure mechanisms were major software
> bugs in the driver stack of PC-oriented machines.

I'm in complete agreement with Bob.

I haven't seen a good analysis of TCP checksum escapes which resulted
from intermediary manipulation (I haven't read the papers, but
hopefully soon), but my hunch is that it's incredibly rare.

An endpoint precipiated TCP checksum `escape' also escape a CRC or any
other similar integrity check.  That is why I think all this
additional integrity checking (on iSCSI headers & data), is an
incredible amount of extra work (not just in computing the CRCs, but
also in designing the SACK mechanism and recovery for digest failures)
for no real gain.  The real loss is that it's immensely slowing
time-to-market for iSCSI (both in the front end specification and the
back end implementation).

A straw-man proposal (very unpopular given where we are, I know) would
be to specify iSCSI without additional integrity checks (other than
what you can get through security mechanisms, which is probably not
visible to iSCSI anyway), and if that `fails' (I'm sure it won't), we
can put an integrity shim between iSCSI and the transport.

One example of how to do this would be Julian's TAF.  Another would be
the WARP RDMA layer.

We don't have to specify how to do this now, and the point is that
it's hard to do so, because we really don't know what problem we're
solving with it.  We're OK as long as we have a way to address it in
the future without completely chucking what already exists.

The other point to remember is that iSCSI still has to make the
ID->Proposed->Draft->Internet traversal, and anybody that thinks it's
going to do that on the first try is kidding themselves.  It's more
important to get SOMETHING out there that exposes the implementation
holes than to design a cathedral on paper.

Steph