SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: Requirements specification



    
    
    David,
    
    The resource consumption I was referring to is not the buffer space but
    rather
    state maintenance; the common figure I was given is 6k/socket.
    Considering also the limited number of sockets in the OS environments
    used by today controllers it did not seem a neat solution.
     And as it was pointed out already from this design you can go to one
    connection/LU
    while the reverse does not hold.
    
    There is also a structural advantage of connecting to a target not a LU -
    the LU map
    may change while you are working.
    
    If you leave all the multiplexing to TCP - including using several physical
    connections
    I am not aware of any good technology to do it today (as TCP traffic is
    bound to the
    end-point IP addresses). We could decide to throw back the balancing need
    to the TCP
    implementers but I am not sure that this will get us very far.
    
    Availability is not an issue for parallel SCSI and it is not there (there
    are no recovery mechanisms on SCSI) ;  FCP designer found out about this
    quite late in the game and moved to FCP-2 (that introduces a fairly complex
    recovery mechanism).
    
    Julo
    
    David Robinson <David.Robinson@EBay.Sun.COM> on 04/08/2000 21:37:51
    
    Please respond to David Robinson <David.Robinson@EBay.Sun.COM>
    
    To:   ips@ece.cmu.edu
    cc:    (bcc: Julian Satran/Haifa/IBM)
    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.
    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