RE: iSCSI reqmts and Ethernet adapters

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

David,

If you look at the "desired" and required features of iSCSI as described in
the requirements document, there is a general structure that could provide
these features.  iSCSI still defines the various commands and the means of
communicating with very little changed from the current proposal.  This
change in structure however will lend itself to a generalized method of
providing hardware features to many other protocols however.

Let me give you an example from the perspective of the SCTP structures as
related to iSCSI:
 - Map the SCSI Tag into the SCTP Data Chunk Stream.
 - Establish hardware vectors associated with Data Chunk Payload Protocol
Identifiers indexed by Stream.
 - Define categories of Payload Protocol IDs to isolate Command, Status,
Data, and iSCSI PDUs.
 - These categories then provide direct placement of stream content
sensitive to iSCSI.

This generalized form of data placement maps nicely into iSCSI, iFCP, FCIP,
RDMA, RPC, NFS, ...

Advantages comes from the removal of error detection, error recovery, flow
control, multi-homing, session recovery, anti-spoofing, anti-DoS, and
independent delivery become common among all of these protocols as well as
many more to come.  The movement to SCTP then is painless.  As it is now,
iSCSI can not meet the SAM-2 requirement and needs renovation due to this
short-coming.  SCTP structures again provides a solution here as well.

iSCSI, iFCP, FCIP, and RDMA could stop looking for a record offload scheme
for TCP.  This record based offload becomes SCTP structure based to create a
common structure.  The SCTP common header could become a TCP option to allow
for negotiation.

I do not see why this subject should not be discussed on IPS as it relates
directly to those protocols that are presently advocating modified network
adapters.  The only aspect that I was requesting was the iSCSI requirements
document adds a requirement to seek this common structure for hardware
support.  You say it is not practical.  I differ with that opinion.

Doug

> > I'll stand by the stated intent of implementing this protocol
> in hardware.
> > The same is also true for iFCP and FCIP.
>
> I never questioned the fact that there will be hardware implementations.
> It still appears to me that no change to the iSCSI requirements document
> is needed to deal with this set of issues.  I am strongly opposed
> to linking
> iSCSI specification development to FCIP and iFCP in a fashion that would
> require all three to be submitted to the IESG as a single set of
> documents.
>
> > Here IPS is developing a framing protocol that increases the level of
> error
> > detection.
>
> I'm sorry, but that's incorrect, because the IPS WG is not developing
> any framing protocol.  draft-williams-tcpulpframe-01.txt and
> draft-otis-tcp-framing-00.txt are both TSVWG drafts, not IPS drafts.
> TSVWG is the right place to work on these sorts of common framing
> mechanisms, and how that work is pursued is at the discretion and
> judgement of TSVWG and its chairs.
>
> > The IPS has made explicit reference to these intentions of
> > having this protocol supported directly in hardware.  I will be happy to
> > show how this protocol can be mapped into a common structure which would
> > avail more protocols to this hardware acceleration at the same time ease
> the
> > transition to SCTP.
>
> The first step of submitting draft-otis-tcp-framing-00.txt has been taken
> (thank you) and the IPS WG will observe and follow what is done in this
> area by TSVWG.
>
> Further discussion of framing belongs on the TSVWG list, not IPS.
>
> Thanks,
> --David
>
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>
>