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

["Y P Cheng" <ycheng@advansys.com>]

> 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

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.