|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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. 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. 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. > 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, fundementally 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. > 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
Home Last updated: Tue Sep 04 01:08:02 2001 6315 messages in chronological order |