RE: iSCSI reqmts and Ethernet adapters

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

iSCSI will not compete with other SCSI transport speeds unless

- significant portions are implemented in hardware

AND
-there is some method of regaining framing in the TCP byte stream to enable
direct iSCSI data placement.

I believe this is sufficiently stated in the iSCSI requirements doc.

Although it is admittedly hard to extract from Doug's long emails, he does
bring up one painful point - even though there are several factual errors
sprinkled throughout that last email.  

The point I chose to extract is that given the first two facts, it is
extremely important to have coordination and attention between the two
efforts (iSCSI definition and framing solution definition).  

Doug states:
> Presently you wish to see this done in a haphazard manner without any
> coordination by the IETF.  This attitude does not reflect the 
> magnitude of this endeavor.

I sympathize with Doug's frustration.  It's a chicken and egg problem that
may cripple iSCSI implementations.  On the one hand, iSCSI definition must
proceed today in order to deliver the specification in a reasonable
timeframe, and a framing solution must proceed in parallel.  On the other
hand, without proper architecture of current iSCSI for a framing solution,
iSCSI may have to be reinvented to perform at 10Gig speeds.  This keeps me
up at night :-)

Another valid point Doug made is that iSCSI, FCIP, and iFCP all have the
same framing needs and should all use the framing solution.  That
recommendation certainly seems sane and within the scope of this WG to
oversee.  Last time I paid attention, FCIP and iFCP were trying to reinvent
this wheel.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com