RE: Request to exclude FC over IP from storage over IP working group charter

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

Should this FC over IP group wish to use IP as a means of encapsulation, I
would like to understand the rational behind exclusion.  There is nothing to
suggest that iSCSI will not suffer from errors injected between the
controller and target.  I do not see iSCSI as the panacea you do.  They
would bring a greater level of expertise to these problems.  As iSCSI
advocates dedicated hardware, what prevents this hardware from implementing
a tunnel end-point at the client?  In fact, that is what iSCSI is.

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> somesh_gupta@hp.com
> Sent: Thursday, August 10, 2000 3:55 PM
> To: ips@ece.cmu.edu; mankin@east.isi.edu; sob@harvard.edu
> Subject: Request to exclude FC over IP from storage over IP working
> group charter
>
>
> Scott/Allsion,
>
> I would urge you to not include FC over IP in the charter of
> the SCSI over IP working group.
>
> Using (TCP)/IP to transport SCSI command blocks fits very
> naturally as part of the SCSI Architecture Model which allows
> for the use of different transports to transfer SCSI
> commands. This include the parallel SCSI, fibre-channel (FCP),
> SCI, and many others including a generic packet transport
> mechanism.
>
> In this case (TCP)/IP acts as a mechanism to transport an
> application level protocol as is intended - preserving the
> protocol layering principles and allowing for an architecturally
> clean solution.
>
> I have been impressed with the momentum behind this idea and saw
> a number of participants at the ietf who were there for this
> session (including myself). This specification will really drive
> the convergence to IP based networks. There is significant
> technical and commercial push for this idea.
>
> FC over IP is a proposal (at least based on the presentation at
> the ietf meeting in Pittsburg) to have IP act as a tunnel
> between two FC islands i.e. there is a fully functional
> fibre-channel island A and a fully functional fibre-channel
> island B, and the proposal is to connect them together using
> an IP based network (don't know if it is to make a super island
> or connect them as a "router" would connect two sub-nets).
>
> I think that the problems being solved and the motivations (from
> a technical perspective - not just a commercial perspective)
> are significantly different.
>
> 1. This is putting a transport over another transport using
> tunneling protocols. A lot of the issues will be about making
> one work while satisfying the contraints and using the
> capabilities of the other. Probably combines the timing and
> recovery mechanisms of the two transports in some horrible way.

You will find write data both solicited and unsolicited equally onerous.
You could do better with control within the gateway and actually provide a
cleaner solution.  As it is now, even acknowledged data may be requested to
be resent and errors will still plague the transport layer using the gateway
model.  iSCSI is not as clean or clear as you think.

> 2. The naming issues are entirely different. In storage over IP,
> each of the partcipating entities is an IP entity.

The debate about LUN within the iSCSI header speaks differently.  There
would not be an IP entity but rather a gateway of some sort.  This gateway
is likely to have Fibre-Channel on one side as example and will carry very
limited state information.

> In FC over IP,
> the participating entities are actually FC entities and will have
> some mechanism of figuring out that the other FC entity lives
> across a tunnel available on the local network. If the proposal
> is to create a larger net, then again the FC port addresses will
> have to partitioned in some interesting way.
>
> 3. How would arbitrated loop work in such an environment of creating
> a large net, or will it connect only Fabric ports together.

You could exclude AL if you wished.

> 4. Security issues are again completely different as the end nodes are
> really not IP entities.

This is true for iSCSI.  This is especially true if you consider the fact
that the iSCSI gateway can not handle separate sessions for each device!

> 5. The protocol encapsulation is also completely different.

Is there something within the charter that excludes valid concepts because
they are different?

> In Summary, putting scsi over ip is architecturally very clean and
> accomodated by the SAM architecture as well as networking layered
> architecture. The end systems communicating in this case are using
> TCP/IP to transfer application (SCSI) PDUs and the problems/solutions
> have a very good framework to work with.
>
> FC tunnels through IP is a commerically important problem to solve
> but is a completely different problem.
>
> I would like to keep both of them seperate so that each of them
> can be successful and provide useful specifications.

I see little difference between what is being called iSCSI and the more
immediately relevant FC over IP that provides both directions of
translation.  You could extract iSCSI from one-half of this tunnel.  It will
more likely work and be understood.

Doug