Subject: RE: iSCSI & iFCP Overlapping (Was iFCP as an IP Storage Work Item)

From: "John Hufferd" <[email-masked]>
Date: Mon, 15 Jan 2001 22:25:52 -0800

YP,
Please refrain from discussing iFCP in any context except what the Draft
supports.
We need to reach consensus on real proposals.
If you want to author another draft we can perhaps discuss that.
The authors of the current draft believe your comments are removing the
focus they need on their iFCP Draft.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403
Internet address: [email-masked]

"Y P Cheng" <[email-masked]>@ece.cmu.edu on 01/15/2001 07:02:50 PM

Sent by:  [email-masked]

To:   John Hufferd/San Jose/IBM@IBMUS
cc:   <[email-masked]>
Subject:  RE: iSCSI & iFCP Overlapping (Was iFCP as an IP Storage Work
      Item)

> Please reframe from speculation about iFCP as an End to End
> protocal.  iFCP has not been proposed by its authors to be End to End,
> and is not up for discussion without an approprate draft.
> The authors and the iFCP Draft clearly define iFCP as an Gateway to
> Gateway protocol.  We are currently having enough problems just working
> on the Gateway to Gateway issues, and do not need to explore areas where
> the Draft did not go. Please lets limit further iFCP discussions to
> iFCP as a Gateway to Gateway protocol.

John,

Thank you for taking time to write a long essay about iFCP in another
posting.  It is not my intent to compare iFCP to an end-to-end solution
like
iSCSI.  Let me respond by staying within the realm of treating iFCP as a
Gateway protocol.  I want to look at the whole issue from another angle.

Most of us would agree the market driver for iSCSI, iFCP and FCIP is the
need to have block-address storage devices on Internet.  The number of new
SSP companies tells the story.  In fact, we can divide the world into two:
clients and SSPs, even when many data centers only serve internal
customers.

As a client, if he has made no investment to fibre channel before, iSCSI is
the nature choice provided his SSP supports iSCSI.  If his SSP has FC or
the
client has already invested in FC, he needs to add a gateway of iFCP or
FCIP
whichever is required by his SSP.  Of course, he can choose iSCSI if it is
supported by his SSP too.  His decision is based on cost, confidence,
availability and performance.  In other words, iSCSI, iFCP, and FCIP are
choices of a client.  Most likely, he is unconcerned whether it is
end-to-end or a gateway until he writes the check.

As an SSP, for some time to come, most will be built around FC and SCSI
devices.  (Some SSP may even wish to build around ATA drives.  Checks with
3ware.)  However, an SSP may choose to "export" its disk drives with iSCSI,
iFCP, or FCIP support.  Notice, what devices an SSP has vs. what it chooses
to export can be unrelated.  It can do so simply with the target HBAs that
support the iSCSI, iFCP or FCIP protocols while the storage devices are
configured as "virtual" drives.  An SSP can invest switches supporting
iSCSI, iFCP and FCIP for export as well, even iFCP is a gateway and iSCSI
is
an end-to-end protocol.  You have mentioned more than once that the iFCP
gateway supplier would support iSCSI in the future.  The exporting protocol
of the devices is only important to the clients as long as they don't have
to throw away the old investment or spend a lot of money buying new
equipment.  Most companies making RAID or large storage boxes is quite
familiar with this virtual device game.  For example, you can choose your
own FC or SCSI connection for a RAID box.

It is in this context that I believe iSCSI and iFCP may have overlapping
utilities because they both take full advantage of IP routing.

Y.P. Cheng, CTO, ConnectCom Solutions Corp.

---

From: "Y P Cheng" <[email-masked]>
Date: Tue, 16 Jan 2001 09:46:08 -0800

> focus they need on their iFCP Draft.

Before focusing on the iFCP draft, I found myself in agreement with Doug in
his statement: "Although you could suggest iFCP is just a gateway to gateway
solution, this does not constrain a gateway if it contains but a single
device nor does it require hallucinations to arrive at that conclusion.  In
that case, the differences between iSCSI and iFCP hinge upon reliance of
existing FCP protocol merged with a lightweight transport.  The motivation
of all proposals is to incorporate IP managed networks rather than rely upon
dedicated fiber for SAN and, in that case, all proposals are in conflict."

Focusing on the draft, iFCP, like the FCIP proposal, does have a distinguish
merit of leveraging off the working FCP headers that most FC adapters and
devices on the market today have no trouble understanding.  If we assume a
SSP is built from parallel SCSI, ATA, and fibre channel devices to support
iFCP with "virtual devices", then, preserving the ELS of fibre channel in
iFCP is not essential.  For example, there is no need for Class 2 parameters
when iFCP has its own ACKs from TCP.  The most important thing for iFCP is
to pass the FCP packets to the other side.  I suspect most ELS parameters
will become much less useful in a IP network.  For example, using iSNS
services, FLOGI and PLOGI might be done locally.  What does EE credit mean
when FCP has its own window size?  What does E_D_TOV mean when TCP has its
own time out? The R_A_TOV has a totally different meaning in a IP network.
Besides focusing on passing FCP packets, just like iSCSI, iFCP needs to
focus on device naming convention and discovery, TCP session creation and
destroy, text parameters for log-in, multiple connections, IPSec and user
authentication, large TCP window for high throughput on network with long
latency, TCP flow control and recovery on lossy connections, frame boundary
and Remote DMA, frame reassembly, etc., etc., ...

In summary, if we do iFCP, lets focus on passing SCSI commands in FCP
format. If we simply wish to connect multiple SAN islands, lets use FCIP.

Y.P. Cheng, ConnectCom Solutions.