RE: Requirements specification

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

David,

Be aware, three days of messages never posted to the reflector and can only
be found in the archive that is now once again online.  It is difficult to
carry on discussions when messages are slow to post or go missing for
several days and then only show up in the archive and not on the reflector
as intended.

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> David Robinson
> Sent: Friday, August 04, 2000 11:38 AM
> To: ips@ece.cmu.edu
> Subject: Re: Requirements specification
>
> > The one additional requirement is availability/fault-tolerance.
>
> I agree that we need to establish the availability requirements
> of IPS, but I see them as orthogonal to the connection discussion.

I think we can reinvent the wheel in this case or understand how the present
networking equipment provides solutions.

> IP already has the wonderful rerouting properties to be fault
> resilient as well as link level technology to do failover.  From
> an IPS perspective the host adapters and the storage adapters are
> the weak links.  This to do a reasonable HA solution you will need
> multiple adapters on both ends which will imply initiator/target
> pairs.

This is the reinventing.  If your intent is to provide a Fibre-Channel
gateway, the only innovation required is to spoof and cache data
solicitations.  You're done; case closed.  If you wish to create a standard
that scales and provides the desired HA features by bring the IP interface
to the device, then much of your architecture and assumptions must change.
It is futile to develop a standard to compete with a Fibre-Channel gateway.
There is nothing being offered by the iSCSI approach this is not already
possible with a Fibre-Channel gateway.  No additional drivers, interfaces,
or system modifications are required beyond the Fibre-Channel gateway.
iSCSI on the other hand, must start from scratch creating the hardware
interface and drivers.

> So I don't see how having multiple TCP connections per session
> will increase availability. Existing HA solutions that layer on top
> of FC or parallel SCSI could just as easily layer on top of IPS.

I suspect this is a separate consideration.  If you wish to make a
Fibre-Channel gateway, then an OC-192 interface at the router will provide
40 Gbit of connectivity which should be plenty for any near term technology.
Cisco has announced such a meld and this removes the perceived 1 Gbit
Ethernet restriction.  See:

http://www.cisco.com/warp/public/146/pressroom/2000/jun00/sp_061300b.htm

> > Your arguments about performance are valid. However I doubt
> that there will
> > be enough incentives - beyond price - to develop things for high end
> > controllers and
> > servers.
> >
> > Enabling multiple connections brings those applications the performance
> > required
> > without any serious implications to the rest of the "family"
> (as I outlined
> > in Pittsburgh
> > controllers and servers that don't need multiple
> connections/session don't
> > have to implement them).
>
> I am not sure that I understand your point here. As has been mentioned by
> others, one performance concern is how to maximize utilization of the
> available link bandwidth with a higher level protocol, fundamentally
> you can never get 100%. Part of the concern is that most existing TCP
> implementations are not scaling up as fast as the link layer protocols.
> To handle this situation people consider some form of aggregation
> of TCP links to relieve the pressure on the implementation side.  The
> question becomes what is the appropriate way to aggregate. If we run
> multiple LUNs over the same session then we will push the TCP
> implementation
> to its limits.  However, if we run a session per LUN, the bandwidth
> pressures will be dramatically less on TCP, we will more easily
> utilize existing and future link layer bandwidth, and simplify the
> multiplexing by leaving it in the TCP layer.

This also makes the proper assumption of taking the interface to the device.
Otherwise we are making a gateway and if that is what you want, then it is
being done already so why make competing standards?

> > Storage traffic requirements will always exceed those of many other
> > applications.
>
> Storage will always exceed thoses of *some* other applications, it is
> easy to find numerous applications that exceed storage requirements.
> I am not clear on the point, but we need to make sure that we clearly
> define what the storage traffic requirements are.
>
> > As for the "one-connection-per-LU" we covered this solution in long
> > discussions
> > and even several full fledged implementation - as it is
> compelingly simple.
> > However the resource consumption is unjustifiably high and the security
> > problems are
> > even worse (the LUs "viewed" by an initiator depend on who he
> says he is)
> > than
> > in the current draft.
>
> I don't agree that the security problems are worse.  For any
> session, whether
> it is a session per target or a session per LUN will need to do full
> security negotiation.  Realitive to the expected lifetime of the sessions
> the time and complexity will be negligible. If we adequately solve it for
> one model it should trivially apply to the other.
>
> I also don't agree on the resource consumption being too high. In terms
> of memory resources the necessary data buffering is dependant on the
> aggregate flow between the target and initiator which will be
> independent of how many connections were used to get the data to
> the other side. There will be more connections, but within typical
> TCP implementations the size and complexity of control blocks is
> minimal.  The ability to switch and manage many connections rapidly
> is a long solved problem. It would be illumninating to hear if Adaptec
> has found that their connection per LUN is resource consuming.
>
> 	-David
>
The only down-side I see with this is that TCP is not intended to be
intermittent at high data rates.

	-Doug