RE: iSCSI: Require iSCSI to use packet formats similar to FC, etc??

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

Marjorie,

I presented a draft which represents an effort to translate iSCSI into a
simple device transport layer.  You will notice there is no information
related to the technology of the device. The command field could be suitable
for any device or application well beyond the constraints of SCSI.  You will
also notice that I have not expected the transport to understand the content
of the device layer information.  I have included some queue management but
have not defined how this management relates to the device.  iSCSI could be
placed upon such a defined transport but you notice that iSCSI defines the
device in addition to the transport layer.  These definitions of the device
should be T10 efforts as a separate specification and perhaps that is where
iSCSI should be defined once a suitable transport is selected.

It should not be difficult to split the transport information from the
device information.  I am concerned that things like ACA involvement
requires the transport to know too much.  Mode page definitions is an
example of that over-reach.  The symmetric stream use in this presented
draft is compatible with the iSCSI connection allegiance.  If these
connections represent separate paths for reliability to the same device,
then being able to maintain coherency over multiple connections is important
and presently, only SCTP provide that level of coherency.

I have also attempted to make this generic device transport layer
independent of the IP transport protocol selection.  You will notice that
the resulting structures are relatively stark.  Add the record tracking of
SCTP to ??P or use directly and the result is a robust transport.  The minor
innovation is a vector placement mode for SCTP as well as integrity digests.
I assume that SCTP will be using suitable error checking.  Those concerned
about data, will likely include integrity and the jury is still out on what
the basic native error checking will be.  If it is not CRC, then a CRC
digest seems like a reasonable alternative.

As a caveat, sequential devices should restrict the number of Associations
to one.  This restriction is less important for random devices, but there
should be some means to resolve the coherency problem of multiple
associations for management result resolution.  A solution would prevent
information arriving from a command that was considered aborted or prevent
conflicted use of command channel.  A resolution to this problem seems to be
related to the device interface.  One possible technique might be to have
the device layer send some type of asynchronous signal on those affected
requests over all active connections but this still seems to be a difficult
and unresolved problem.  Keeping the Association to one is one method but
not likely desired.

My thought was to have a command channel on each connection dedicated to
resolving management command coherency.  This dedicated channel would
respond to all management commands.  All dedicated channels responding would
be required to validate the management response.  These one to many
management command responses could be done by or at the device layer.

Doug


> > As the rules change from technology to technology, there are
> > issues involved
> > in this endeavor that will place into focus some potential
> > problems.  I tend
> > to think that an independent delivery protocol could be
> > developed.
>
> An independant protocol that is agnostic to the transport medium would
> probably be too general to be optimal in any specific transport
> environment.
> I think the solution is to make SCSI truely independant of the transport
> (strictly layered on top of the transport).  It seems that T10 is
> realizing
> this and some are working towards that goal.
>
> IMHO, requiring that iSCSI match other transport formats is going at the
> problem from the wrong end.
>
> Marj
>