unsubscribe

["Havard, Philippe" <Philippe.Havard@compaq.com>]

-----Original Message-----
From: John Hufferd/San Jose/IBM [mailto:hufferd@us.ibm.com]
Sent: vendredi 18 aout 2000 10:03
To: ips@ece.cmu.edu
Subject: RE: FC/IP vs. iSCSI & Towards Consensus on TCP Connections


I agree with Kalman, and I think he stated it well.  Further, we had -- I
thought -- a Schedule for focus items, on which we were to concentrate.  I
think we are straying into distance corners, and it is not clear that this
is useful.  If it were possible to either separate the FC on IP stuff, or
perhaps delay this discussion I think it will be very useful (Note I did
not say ignore).  I think we need to focus on the iSCSI protocols and
refine it as we think it should be, and try to meet the direction and
schedule that David Black laid out.

I understand that some folks want to have many TCP connections to a storage
entity, including at least one TCP/IP connection per LUNs.  I think it has
been agreed by Julian that iSCSI will support that, with some extensions
which he suggested.  Even though most folks will not implement their
Storage Controllers in that manor, I think that issue is perhaps settled.
Julian could perhaps restate the change that would make the TCP per LUN
folks (if more then one) happy. This may permit us to really move off of
point "A" (specified by David Black as "Should iSCSI require a TCP
connection per LUN?").  If that is so, then I also submit that we have not
been focusing enough time on point "B" ("Should iSCSI have a session
abstraction that binds multiple TCP connections into one iSCSI connection?
").   I would like to hear from folks that believe that iSCSI does not
support any number of conversations per session.  I say this because I
thought iSCSI could support one or more TCP/IP connections per session.
Therefore, the various implementers can decide on what they will support --
one, or more then one, compatibly with any other implementations since one
connection per session is the default.  I say default since the target can
refuse or accept more then one connection per session.

So I would like to understand if this is acceptable -- especially since as
we have seen that working group  have both positions represented (one &
more then one).

I think that it might be correct  that the current spec satisfies the need
enough to say that point "B" has been addressed.
.
.
John L. Hufferd


meth@il.ibm.com@ece.cmu.edu on 08/18/2000 12:03:49 AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: FC/IP vs. iSCSI







Doug wrote:

"In reality, the iSCSI proposal was to a be a modification for a
Fibre-Channel
controller.  A complete and unaltered encapsulation is the most
straightforward approach and likely with the lowest overhead and risk."

This is not correct. The original iSCSI proposal was meant (at least by
some of the authors) to provide a SAM-2 compliant native transport for SCSI
over (specifically) TCP. The ultimate goal is to have a single network
infrastructure for regular internet traffic and for storage traffic; i.e.
the ultimate goal is to not need a separate Fibre-Channel infrastructure.
(Sorry Fibre-Channel fans ;-).) The same management tools and off-the-shelf
components can then be used for both ordinary internet infrastructure and
for remote storage infrastructure.

Now the IP Storage WG charter is broader than what iSCSI provides. There is
no need for iSCSI to provide a universal solution to all IP storage
problems. Let's develop the iSCSI protocol to do well what it was
originally designed for: native SCSI over TCP. We have to keep in mind,
however, that in order for iSCSI to be adopted, we will probably have to
provide some support for existing storage SAN infrastructure (i.e. Fibre
Channel) bridging. There is no need, however, to make that the primary
focus of the iSCSI protocol.

- Kalman