iSCSI reqmts and Ethernet adapters

[Black_David@emc.com]

> This requirements document makes it clear there is expectation of
modifying
> Ethernet adapters to support this protocol.  Should this required hardware
> support be made in a general fashion to allow common use among other
> protocols?  

There are at least two announced iSCSI products and
an open source driver that do not require any
modifications to existing Ethernet adapters,
so such modifications are clearly not a requirement.

> This hardware requirement is primarily based on two
> requirements, to increase the level of error detection and to allow
framing.

Error detection (i.e., CRC or checksum) can be done in
software as Doug has frequently pointed out on this list.
I don't think the statement about IPS and TSVWG pursuing
a common error detection algorithm is correct -- while
I'll defer to the ADs (who are the chairs of TSVWG), I
believe TSVWG has significant interest in an improved
checksum (e.g., Adler-32 based on adding 16-bit quantities
instead of 8-bit), whereas IPS intends to use CRCs.

Framing is optional and being pursued in a layered fashion
as called for by the WG charter.  The instructions in
the WG charter should be sufficient - adding text to the
iSCSI requirements document that introduces otherwise
unneeded dependencies on other protocol specification
efforts (i.e., iFCP, FCIP) is a bad idea.  Heaven help
us if we have to submit all the protocol drafts for the
IPS WG to the IESG in one big bundle - at the very least
the IESG will be annoyed, and annoying the IESG has all
sorts of bad side effects ;-).

I don't see that any change to the iSCSI requirements draft
is needed in either of these areas based on this set of
comments.

Doug also posted a pointer to the wrong draft - I suspect
he meant to point to draft-otis-tcp-framing-00.txt.

--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
---------------------------------------------------


> -----Original Message-----
> From:	Douglas Otis [SMTP:dotis@sanlight.net]
> Sent:	Monday, April 23, 2001 4:15 PM
> To:	KRUEGER,MARJORIE (HP-Roseville,ex1); Ips Reflector (E-mail)
> Cc:	Allison Mankin; David Black; Elizabeth G Rodriguez (Elizabeth);
> Scott Bradner
> Subject:	RE: I-D ACTION:draft-ietf-ips-iscsi-reqmts-03.txt
> 
> Marjorie,
> 
> This requirements document makes it clear there is expectation of
> modifying
> Ethernet adapters to support this protocol.  Should this required hardware
> support be made in a general fashion to allow common use among other
> protocols?  This hardware requirement is primarily based on two
> requirements, to increase the level of error detection and to allow
> framing.
> Presently, IETF supports a framing protocol that also increases the level
> of
> error detection.
> 
> Presently TSVWG and IPS are working on a common error detection algorithm.
> In addition, there are two other protocols expecting hardware for framing
> and error detection.  This is iFCP and FCIP.
> 
> See:
> http://www.ietf.org/internet-drafts/draft-ietf-ips-fcencapsulation-00.txt
> 
> It is possible to have all these protocols use the same error detection
> and
> framing.  If this MUST be done using TCP, as this requirement document
> demands, then here is a possible general propose header that would allow
> common use of hardware and a easy transition into SCTP.
> 
> I will be happy to define a mapping from the present protocols into this
> generalized form.  The advantage should be obvious.  One Ethernet adapter
> can handle these various protocols without specialized hardware for each.
> 
> For those wishing to update and route based on encapsulated headers, a
> fix-up field at the end of these headers will allow use of a common error
> scheme using header fix-up.
> 
> Here is an example of how TCP can be made to look like SCTP.
> http://www.ietf.org/internet-drafts/draft-otis-iscsi-fullack-00.txt
> 
> This header could become a TCP option field to allow for negotiation.
> 
> P.S.
> One additional question however.
> 
> On page 18,
>    "The iSCSI protocol document SHOULD NOT define the management
>    architecture for iSCSI within the network infrastructure."
> 
> What does this mean?
> 
> Doug
> 
> 
> > The IP Storage Working group is chartered with developing
> > comprehensive technology to transport block storage data
> > over IP protocols.  This effort includes a protocol to
> > transport the Small Computer Systems Interface (SCSI)
> > protocol over the internet (iSCSI).
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-reqmts-03.txt
> >