Re: iSCSI Autosense Consensus, Connection next steps

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

> You talked about Transport layer and Wedge layers.  I guess I do not know
> exactly what to call iSCSI if given these two options, other then to
> consider iSCSI part of the SCSI Transport (layer).  It is a device specific
> driver, which in this case deals with iSCSI Devices.

I guess we have a terminological gap here.

Here's how I understand the terms.

Generally, I believe the term `transport layer' is used to describe
the uppermost layer in a stack that carries data, without any
particular thought to what the data is.  For example, ST, TCP, UDP,
FC-2.

Above the transport layer are layers that know what the particular
data being carried is e.g. FTP, NFS, HTTP.  Clearly this `knowing' is
relative---an HTTP layer doesn't know everything about the data it's
carrying, but it knows more than nothing.  These more specialized
protocols are called upper layer protocols (ULPs).  The iSCSI protocol
is one of these ULPs.

The layers above iSCSI are the parts of a SCSI stack.  Typically this
includes a mux/demux layer, and, above that, a set of SCSI peripheral
drivers (disk, tape, cluster communication, etc..).  SCSI wedge
drivers are in this SCSI stack, hooked somehow (on top, bottom or
possibly in the guts), to the mux/demux layer.

> I do not think we should call iSCSI a Wedge Driver.

Agreed.  My mistake if I suggested that that's how I was thinking of
it.  iSCSI is a protocol.  An iSCSI driver is both a SCSI port driver
and a network protocol driver, certainly not a wedge driver.

> Having said all that, I think the point you wanted to make was: if the
> command load balancing functions can not be done in the xxxx/IP transport
> then no one should do it.

No.  The point I am trying to make is that if CONNECTION-level load
balancing (or connection bundling) services are not available from the
transport layer (TCP, ST, STCP, etc.), iSCSI should not take this
responsibility for itself.  I did not say no one should do it.  The
clear implication if iSCSI does not directly support transport
connection bundling, is that a layer above iSCSI will do it.  That is
what wedge drivers do presently.

When we started bringing up FC controllers, existing ||SCSI
multipathing code worked as-is.  Nobody in the legacy (%^) network
SCSI community (FCP) seems to feel a compelling need to add transport
layer connection bundling.  We certainly didn't see any need to
reinvent that wheel early on, and I still don't see it.

> I think that David is correct the only point that I was making was that if
> iSCSI was able to do the load balancing and some Generic Alternate Path
> recovery, that the Vendor Specific Wedge Drivers will be much simpler.

Or, my guess is that the support just won't be used.  After all, these
same wedge drivers already support all types of different SCSI
interfaces (||, FCP, SST etc.) concurrently in a more or less
interface independent way.  Why gunk up a piece of mission-critical
code with additional paths that don't offer any user-visible
improvement?

If we could get a credible wedge driver person to come say
`absolutely, connection bundling below the SCSI stack is what we
need!', I'll roll over.  As it is, I think we're trying to build this
feature primarily on speculation.

My second objection is that I think it's an architectural error to
start filling iSCSI with what are essentially transport-layer
enhancements.  iSCSI says what data to move, and it is the transport
layer's requirement to move it as fast and as reliably as possible by
any means available.  If you don't dig what the current transport has
to offer, use another one.  The advantage a ULP gets by not trying to
`enhance' the transport-layer, is that it is relatively immune to
modifications to the underlying transport.

None of the arguments made for iSCSI connection bundling are unique to
storage.  If connection bundling is so compelling, TCP or some
relative will develop its own connection bundling mechanism, and then
iSCSI can take advantage of it more or less transparently.

Steph