RE: Towards Consensus on TCP Connections

[hufferd@us.ibm.com]

Stephen,
That is a fair question.  At this moment I think that Multiple TCP/IP
Connections per session can be useful, but I am neither a rabid fan nor a
rabid detractor.  The people involved have put a lot of effort into
understanding the problems and solutions that this approach both cause and
solve.  The biggest goal that we want to solve in the long run is how we
can actually use the complete set of connections to both sending Commands &
Data as well as receiving Data, on any connection.  If we had that
capability, I would be a Rabid Fan of Multiple TCP/IP Connections per
session.  We, IBM, and EMC,  etc. have done this kind of thing on our large
storage controller connected to S390 processors for years, and the results
has been extremely valuable.

The iSCSI team, however, gave up on this approach for the initial
specifications, since it seemed to be very difficult to either explain or
perhaps implement across multiple NIC Adapters.  Regardless, they then
attempted to keep as much as they could of the Multiple TCP/IP Connections
per Session, but have the data return on the Command Connection.  This is
perhaps better then not having this capability, but looses some of the key
value that we originally wanted.  I expected that the IPS group would look
at this carefully and see if they could either come up with a way to do it
even better.  That is, approach the goal of permitting the Storage
Controller to respond on any Connection of a Session with the approprate
Data and Status, if the preferred/default one is busy.

I even hallucinated my own, perhaps not well thought out idea, that perhaps
something like a RTT could be sent on another Session Connection (not the
one on which the  command was received), to alert that Initiator side that
data from command xxxx was about to be sent on some specific Session
Connection.  (I said that it was not well thought out!)
In this way, or some other better way, it might be possible to use all the
Session Connections for Both Data and Commands.

I can accept the fact that we are not completely there at this time, and
can accept the fact that what we have now may be all we can do for the
first release of this standard.  I feel this is reasonable and possible,
since it has a base on which to do even better things in subsequent
versions of the standard.

Having said that, let me put on my product hat and talk about what I think
many of us will do as soon as possible.  And that is to use a subset of the
Multiple TCP/IP Connections per Session --- that is, one TCP/IP Connection
per Session with possibly multiple Session to the same target (probably on
different Host NICs). This will mean, however, that the Host systems will
need to have the Session Balancing software which we and our competitors
current have available to run on the host when they have multiple FC
connections.

Since IBM and others already have such code, it seems like the path of
least resistance.  The problem is, that we and others will have to keep
this unique code around, which is independent of this Standard, and we and
our competitors may  have to write/maintain this code in addition to the
iSCSI Device Drivers.  If it was all in the Standard, then the Host
customer could choose the approprate code that went with its iSCSI
compatible NICs, and no other separate piece of code would have to be
developed and maintained (or installed).

I think that some companies will also attempt to get to the Multiple
Conversations per Session, since it will give their customers the advantage
of not having to install  Storage Vendor specific software to Balance
between the various Connections.  I think this will be goodness.

So let me net this: I think that Multiple Conversations per Session are
useful, and can be even more useful when extended in the future.  I think
that using the subset of one Conversation per Session (with probable
multiple session to a target) is something that many/most of the companies
will use, since it is simpler and they already have the connection
balancing software.  But I think the end-game must be multiple
conversations per session that carry commands and data independently.


.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSD San Jose Ca
(408) 256-0403, Tie: 276-0403
Internet address: hufferd@us.ibm.com
Notes address: John Hufferd/San Jose/IBM @ IBMUS
VM address: hufferd at IBMUSM54


Stephen Byan <Stephen.Byan@quantum.com>@ece.cmu.edu on 08/11/2000 02:08:46
PM

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


To:   ips@ece.cmu.edu
cc:   Stephen Byan <Stephen.Byan@quantum.com>, Douglas Otis
      <dotis@sanlight.net>
Subject:  RE: Towards Consensus on TCP Connections



hufferd@us.ibm.com [mailto:hufferd@us.ibm.com] wrote:

> Now, do you think that now we can shelve the disk drive discussion and
> focus more on the Storage Controller functions.

I hope no one thinks I'm trying to derail the Storage Controller portion of
our discussions. I'm simply explaining why I advocate my position in favor
of multiple TCP connections per iSCSI session.

> So I would like to propose, again, that we get back on track and work
> issues which apply first to Storage Controllers.

OK. So do you favor or oppose multiple TCP connections per iSCSI session?
Your position wasn't clear to me from your message.

Thanks.

Regards,
-Steve

Steve Byan
<stephen.byan@quantum.com>
Design Engineer
MS 1-3/E23
333 South Street
Shrewsbury, MA 01545
(508)770-3414
fax: (508)770-2604