RE: iSCSI: Session Consensus/Plan -- SCTP (FCoverIP)

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

John,

The journey of a thousand miles begins with the first step.
http://www.ietf.org/internet-drafts/draft-otis-fc-sctp-ip-00.txt


In conjunction with
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-13.txt

My apologies for not following proper procedures previously.

Problems to overcome implementating a new protocol for routers and switches
that look beyond IP layers should be of the same order of difficulty as the
IP datagram protocol initially proposed for FCoverIP.    At least the
expensive fragmentation is handled within the SCTP protocol to ensure a
normal router does not see a burden.  The remaining work is simply to
configure the channels. (Flipping streams on buried protocols, splitting and
merging streams to match technologies at opposite ends etc.)  I would hope
to limit this to simple structures with a common header to establish
revision level negotiations.  Any ideas?

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> John Hufferd/San Jose/IBM
> Sent: Wednesday, August 23, 2000 7:04 PM
> To: Black_David@emc.com
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: Session Consensus/Plan -- SCTP
>
>
> The objection that I have to SCTP has to do with getting HW support, and
> normal customer acceptance.  I have the following points:
>
> 1. The NIC industry is rapidly moving to supporting TCP/IP offload and
> acceleration of OS native TCP/IP Stacks.  This is being done by major
> vendors making major investments in ASICs etc.  they are NOT building SCTP
> Hardware.  They have business cases that support TCP/IP in
> hardware, and we
> wanted to exploit this by having iSCSI ride on this wave.
>
> 2. SCTP is a non proven technology from a robust and load situation.  It
> may or may not be great, but we can not afford to find out about a "oops"
> situation in load, stability, scaling, etc. as we try to deploy it in vast
> numbers.
>
> 3. We will need to get the Switch and Router folks to also
> support SCTP and
> to do it in Hardware so that the speed and throughput can be
> maintained.  I
> do not see that happening, at least not right away, when we need to get
> volumes moving in order to validate the IP storage SAN concept.
>
> 4. I do not think that we can afford to put together the marketing effort
> that will be needed to convince customers that SCTP is a great thing, at
> the same time that we are trying to convince them that an IP SAN is the
> right answer.  Having Two new concept sales points is going to divide the
> focus and confuse the issues.  It would be much better to focus on the
> concept of an IP SAN that supports the well known and understood
> TCP/IP, to
> which the customer feels comfortable, and for which they have various
> management tools.
>
> 5. Because of point 1-3 above, I think we will have a hard time
> getting the
> customers to accept SCTP, since there will not be the HW and
> therefore  the
> performance we need, when we need it.
>
> .
> .
> .
> John L. Hufferd
>